Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Jun 3, 2011 at 1:19 PM, Tom Lane <t...@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. I don't really want pg_dump dumping this kind of
thing, because that locks us down to supporting it that way forever.
> 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.
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. But again, that happens at plan time, it's not what gets
stored in rules. And that matters, because locking down the column
expansion too early would break the response to ADD/DROP COLUMN on
one of the input tables.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
