Re: [HACKERS] column aliases

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] column aliases
Дата
Msg-id 6317.948653189@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] column aliases  (Don Baccus <dhogaza@pacifier.com>)
Ответы Re: column aliases  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Implementing STDDEV and VARIANCE
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: [HACKERS] Happy column dropping