Re: Fix for tablename in targetlist

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix for tablename in targetlist
Date: 2001-05-19 14:50:31
Message-ID: 29912.990283831@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2001-05-19 15:12:53 Re: Re: External search engine, advice
Previous Message Tom Lane 2001-05-19 14:44:13 Re: Plans for solving the VACUUM problem