Re: Fix for tablename in targetlist - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Fix for tablename in targetlist
Date
Msg-id Pine.LNX.4.21.0106131210490.31744-100000@linuxworld.com.au
Whole thread Raw
In response to Re: Fix for tablename in targetlist  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Fix for tablename in targetlist  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Fix for tablename in targetlist  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] Australian timezone configure option
Next
From: Bruce Momjian
Date:
Subject: Re: Fix for tablename in targetlist