Thread: New TODO item

New TODO item

From
Bruce Momjian
Date:
New item for TODO list:

* SELECT aliname FROM pg_class aliname generates strange error
test=> SELECT aliname FROM pg_class aliname;NOTICE:  unknown node tag 704 in rangeTableEntry_used()NOTICE:  Node is: {
IDENT"aliname" }NOTICE:  unknown node tag 704 in fireRIRonSubselect()NOTICE:  Node is: { IDENT "aliname" }ERROR:
copyObject:don't know how to copy 704
 

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@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
 


Re: [HACKERS] New TODO item

From
wieck@debis.com (Jan Wieck)
Date:
Bruce Momjian wrote:

>
> New item for TODO list:
>
> * SELECT aliname FROM pg_class aliname generates strange error
>
>
>    test=> SELECT aliname FROM pg_class aliname;
>    NOTICE:  unknown node tag 704 in rangeTableEntry_used()
>    NOTICE:  Node is: { IDENT "aliname" }
>    NOTICE:  unknown node tag 704 in fireRIRonSubselect()
>    NOTICE:  Node is: { IDENT "aliname" }
>    ERROR:  copyObject: don't know how to copy 704

    Without  looking  at  anything  I  can tell that these NOTICE
    messages got spit out of the rewriter (I  placed  them  there
    along with the additional NOTICE telling nodeToString()).

    It looks to me that the targetlist contains a bare identifier
    which the parser wasn't able to change into  a  Var  node  or
    something  else.  That  should  never  be  possible.  A valid
    querytree cannot contain identifiers where the parser  didn't
    knew from which rangetable entry they should come from.

    Look  at  the  parser  output  (-d4)  and you'll see the same
    problems the rewriter just told.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

Re: [HACKERS] New TODO item

From
Tom Lane
Date:
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> New item for TODO list:
> * SELECT aliname FROM pg_class aliname generates strange error

You don't need the alias; "SELECT pg_class FROM pg_class" generates
the same behavior.

Looks to me like the parser is failing to reject this query as malformed.
transformIdent() is willing to take either a column name or a relation
name (why?), and no one upstream is rejecting the relation-name case.

End result is an untransformed Ident node gets left in the parser
output, and neither the rewriter nor the planner know what to do with
it.
        regards, tom lane


Re: [HACKERS] New TODO item

From
Bruce Momjian
Date:
>     Without  looking  at  anything  I  can tell that these NOTICE
>     messages got spit out of the rewriter (I  placed  them  there
>     along with the additional NOTICE telling nodeToString()).
> 
>     It looks to me that the targetlist contains a bare identifier
>     which the parser wasn't able to change into  a  Var  node  or
>     something  else.  That  should  never  be  possible.  A valid
>     querytree cannot contain identifiers where the parser  didn't
>     knew from which rangetable entry they should come from.
> 
>     Look  at  the  parser  output  (-d4)  and you'll see the same
>     problems the rewriter just told.

Yes.  The parser should never allow this.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@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
 


Re: [HACKERS] New TODO item

From
Bruce Momjian
Date:
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > New item for TODO list:
> > * SELECT aliname FROM pg_class aliname generates strange error
> 
> You don't need the alias; "SELECT pg_class FROM pg_class" generates
> the same behavior.

TODO updated.

> 
> Looks to me like the parser is failing to reject this query as malformed.
> transformIdent() is willing to take either a column name or a relation
> name (why?), and no one upstream is rejecting the relation-name case.

There is some reason for this that I think Thomas can tell us.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@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
 


Re: [HACKERS] New TODO item

From
Thomas Lockhart
Date:
> > Looks to me like the parser is failing to reject this query as malformed.
> > transformIdent() is willing to take either a column name or a relation
> > name (why?), and no one upstream is rejecting the relation-name case.
> There is some reason for this that I think Thomas can tell us.

Moi? Why drag me into this? ;)

I'm not recalling why we would want to handle bare relation names in
an expression, but it does seem that a flag is being set in
transformIdent() which one could test later to verify that you have a
column. afaik this code predates my contributions, so I don't have
much insight into it. (It is true that there are a few extensions to
the SQL syntax which are holdovers from the PostQuel language, which
explains a few odd features in the parser.)

Would you prefer that we do nothing until I have a chance to research
this some more, or is someone going to dive in?
                     - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California


Re: [HACKERS] New TODO item

From
Tom Lane
Date:
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'm not recalling why we would want to handle bare relation names in
> an expression, ...
> Would you prefer that we do nothing until I have a chance to research
> this some more, or is someone going to dive in?

Research away.  As far as I can see, this isn't affecting processing of
any valid queries; it's just a matter of less-than-desirable response
to an invalid one.  So I think we can take our time about fixing it.
I know I've got other things to work on...
        regards, tom lane