> On Tue, 12 Jun 2001, Bruce Momjian wrote:
>> I am confused. I thought I fixed this about a month ago. Do we need
>> more coded added here?
You did, and we don't. In current sources:
regression=# SELECT pg_class FROM pg_class;
ERROR: You can't use relation names alone in the target list,
Bruce,
On Tue, 12 Jun 2001, Bruce Momjian wrote:
> > Bruce,
> >
> > On Fri, 18 May 2001, Bruce Momjian wrote:
> >
> > > We have on the TODO list:
> > >
> > > * SELECT pg_class FROM pg_class generates strange error
> > >
> > > It passes the tablename as targetlist all the way to the executo
Bruce,
On Fri, 18 May 2001, Bruce Momjian wrote:
> We have on the TODO list:
>
> * SELECT pg_class FROM pg_class generates strange error
>
> It passes the tablename as targetlist all the way to the executor, where
> it throws an error about Node 704 unkown.
The problem is caused in tran
On Sat, May 19, 2001 at 10:50:31AM -0400, Tom Lane wrote:
> 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
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> select pg_class from pg_class;
> Probably a valid interpretation would be if type pg_class or opaque had an
> output function.
Hmm, good point. We shouldn't foreclose the possibility of handling
things that way. Okay, I'm convinced: allo
> True, although there's a certain inconsistency in allowing a whole row
> to be passed to a function by
>
> select foo(pg_class) from pg_class;
>
> and not allowing the same row to be output by
Imho there is a big difference between the two. The foo(pg_class) calls a function
with argu
> > I tend to agree that we should not change the code to make "select tab"
> > work, on the grounds of error-proneness.
>
> OK, here is another patch that does this:
>
> test=> select test from test;
>test
> --
> 1
> (1 row)
I object also. It is not a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> In fact, I was
> right that you have to call transformTargetEntry() -> transformExpr() ->
> transformIdent() to get isRel set, and I have to do the longer fix.
Yes, I would think that you should do transformTargetEntry() first and
then look to see if yo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, here is another patch that does this:
That seems considerably uglier than your first patch. In particular,
why aren't you looking for isRel being set in the Ident node? It
looks to me like you may have changed the behavior in the case where
the Id
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> No really, I don't see a point of not enforcing the correct syntax, when
> adding '.*' is all it takes to get the alternative behaviour in a standard
> way.
True, although there's a certain inconsistency in allowing a whole row
to be passed to a func
Bruce Momjian <[EMAIL PROTECTED]> writes:
> 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 i
Peter Eisentraut <[EMAIL PROTECTED]> 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. Wha
12 matches
Mail list logo
