> > 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 ;-)
I thought about adding the *. We already allow 'SELECT tab.*'. Should
'SELECT tab' behave the same? It certainly could.
Actually, I just tried:test=> select test;ERROR: Attribute 'test' not foundtest=> select test.*; test ------ 1(1
row)
Seems a tablename with no FROM clause doesn't get marked as isRel
because it is not in the range table to be matched.
What would happen if we added auto-star is that a table name in a target
list would automatically become tablename.*. Seems it is too prone to
cause bad queries to be accepted.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026