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 found
test=> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026