Re: Fix for tablename in targetlist

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fix for tablename in targetlist
Дата
Msg-id 29912.990283831@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fix for tablename in targetlist  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Fix for tablename in targetlist  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Fix for tablename in targetlist  (Peter Eisentraut <peter_e@gmx.net>)
Re: Fix for tablename in targetlist  (Michael Samuel <michael@miknet.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> This patch fixes the problem by generating an error in the parser:
>> 
>> test=> select pg_class from pg_class;
>> ERROR:  You can't use a relation alone in a target list.

> Maybe it's the parser that's getting it wrong.  What if pg_class has a
> column called pg_class?

Not an issue: the ambiguous name will be resolved as a column name, and
it will be so resolved before this code executes.  We do know at this
point that we have an unadorned relation name; the question is what
to do with it.

I had a thought this morning that raising an error may be the wrong
thing to do.  We could instead choose to expand the name into
"pg_class.*", which would take only a little more code and would
arguably do something useful instead of useless.  (I suspect that the
fjoin stuff that still remains in the backend was originally designed
to support exactly this interpretation.)

Of course, if we did that, then "select huge_table;" might spit back
a lot of stuff at you before you remembered you'd left off the rest
of the query ;-)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Plans for solving the VACUUM problem
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Plans for solving the VACUUM problem