Re: [HACKERS] column aliases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Don Baccus <dhogaza(at)pacifier(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] column aliases
Date: 2000-01-23 18:46:29
Message-ID: 6317.948653189@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 wrong table 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-01-23 18:53:18 Re: [HACKERS] Happy column dropping
Previous Message Tom Lane 2000-01-23 18:27:01 Re: [HACKERS] Implementing STDDEV and VARIANCE