Re: [HACKERS] column aliases - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] column aliases
Date
Msg-id 6317.948653189@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] column aliases  (Don Baccus <dhogaza@pacifier.com>)
Responses Re: column aliases
List pgsql-hackers
>> What it looks like to me is that we have a bug in the expansion of '*'.
>> It should be generating columns for both the explicit and the implicit
>> FROM clause, but it's evidently deciding that it should only produce
>> output columns for the first one.

I thought that the behavior had something to do with the fact that
the underlying table was the same for both the explicit and the implicit
rangetable entry, but not so.  In fact, ExpandAllTables() deliberately
refrains from expanding implicit entries, and always has AFAICT:
       /*        * we only expand those listed in the from clause. (This will        * also prevent us from using the
wrongtable in inserts: eg.        * tenk2 in "insert into tenk2 select * from tenk1;")        */       if
(!rte->inFromCl)          continue;
 

I think the comment in parentheses is no longer applicable, but there
are other sources of implicit rangetable entries besides this particular
feature --- rules and set functions both seem to add them.  So I'm not
sure what we might break by changing it.

I'm inclined to leave this behavior alone, and go back to the idea of
emitting warning notices when an implicit FROM clause is added.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Implementing STDDEV and VARIANCE
Next
From: Hannu Krosing
Date:
Subject: Re: [HACKERS] Happy column dropping