Обсуждение: New TODO item
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
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) #
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
> 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
> 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
> > 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
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