On Fri, Jun 3, 2011 at 2:21 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Now, if the query doesn't involve any explicit reference to "joinalias.=
*",
>>> we could probably fake it with some ugly thing involving
>>> COALESCE(leftcol, rightcol) ... but I don't think people will want to
>>> read that, and anyway the idea falls apart as soon as you do have a
>>> whole-row reference.
>
>> Well, it gets internally translated to COALESCE(leftcol, rightcol)
>
> We do that during planning; it's not the form that gets stored in views
> or dumped by pg_dump. =A0I don't really want pg_dump dumping this kind of
> thing, because that locks us down to supporting it that way forever.
Hmm.
>> I'm not seeing the problem with whole-row references; can you elaborate =
on that?
>
> SELECT somefunc(j.*) FROM (tab1 JOIN tab2 USING (id)) j;
>
> The shape of the record passed to somefunc() depends on removal of the
> second id column.
Ah, yes.
> Now you might claim that we could expand the j.* to a ROW() construct
> with an explicit list of columns, which indeed is what happens
> internally. =A0But again, that happens at plan time, it's not what gets
> stored in rules. =A0And that matters, because locking down the column
> expansion too early would break the response to ADD/DROP COLUMN on
> one of the input tables.
Fair enough, but the current implementation with respect to ADD
COLUMN. And RENAME COLUMN.
If your point here is that you don't want to spend time hacking on
this because it's a fairly marginal feature and therefore not terribly
high on your priority list, I can understand that. But if you're
actually defending the current implementation, I'm going to have to
respectfully disagree. It's broken, and it sucks, and this is not the
first complaint we've had about it.
--=20
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company