Re: [HACKERS] Parser/planner and column aliases - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Parser/planner and column aliases
Date
Msg-id 28414.949599022@sss.pgh.pa.us
Whole thread Raw
In response to Parser/planner and column aliases  (Thomas Lockhart <lockhart@alumni.caltech.edu>)
List pgsql-hackers
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'm running across the behavior that an explicit select as above
> works, but if I try a wildcard expansion (select *...) instead of the
> explicit column listing the planner decides it needs to do some wild
> nested join stuff:

> Nested Loop  (cost=43043.00 rows=1000000 width=12)
>   -> Seq Scan on t2 ty  (cost=43.00 rows=1000 width=4)
>   -> Seq Scan  (cost=43.00 rows=1000 width=8)

Man, that's weird-looking.  What happened to the table name in the
second Seq Scan line?  I think you must be passing a broken rangetable
list.

My guess is that expansion of "*" is somehow failing to recognize that
it should be using the same RTE for all columns, and is causing an
extra bogus RTE to get added to the list.  Put two RTEs in there and
you get a join...
        regards, tom lane

BTW, this example reminds me once again that un-pretty-printed
EXPLAIN VERBOSE output is damn near unreadable.  Would anyone object
if it got formatted the same as what goes to the postmaster log?
(It used to be unsafe to do that, but now that we can cope with
unlimited-length NOTICE messages I see no real good reason not to
format it more nicely.)


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Another nasty cache problem
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL