Re: Fix for tablename in targetlist
От | Gavin Sherry |
---|---|
Тема | Re: Fix for tablename in targetlist |
Дата | |
Msg-id | Pine.LNX.4.21.0106131210490.31744-100000@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: Fix for tablename in targetlist (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Fix for tablename in targetlist
Re: Fix for tablename in targetlist |
Список | pgsql-hackers |
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 executor, where > > > it throws an error about Node 704 unkown. > > > > The problem is caused in transformIdent() (parse_expr.c): > > > > if (ident->indirection == NIL && > > refnameRangeTableEntry(pstate, ident->name) != NULL) > > { > > ident->isRel = TRUE; > > result = (Node *) ident; > > } > > > > It is pretty clear what is happening here. ident->name is a member of > > range table so the type of ident is not changed, as would be the case with > > an attribute. Commenting this code out means that result = NULL and the > > error 'Attribute 'pg_class' not found'. This, in my opinion, is the > > correct error to be generated. Moreover, I cannot find any flow on effect > > which may result from removing this code -- regression tests all > > pass. From what I can tell, all transformations of Nodes which are of type > > Ident should have already been transformed anyway -- have I over looked > > something? > > I am confused. I thought I fixed this about a month ago. Do we need > more coded added here? > > You are suggesting throwing an error as soon as an idend appears as a > relation. I don't know enough about the code to be sure that is OK. I > realize the regression tests pass. Removing the said code and not applying your patch allows the parser to recognise that pg_class is not an attribute of pg_class relation. There does not seem to be any side effect from removing this code, though I would like to see if someone can find fault in that. If there is no problem, then -- in light of the discussion on this a month or so ago -- SELECT pg_class FROM pg_class should be be considered 'select the column pg_class from the pg_class relation' which is the same as SELECT nosuchcolumn FROM pg_class. Isn't this the most effective way to solve the problem then? Thanks Gavin
В списке pgsql-hackers по дате отправления: