Re: Fix for tablename in targetlist

> > 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