New TODO item

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, Pennsylvania 19026

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, Pennsylvania 19026

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

(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?

IMHO a tablename after select is only valid if there is a point and
attribute or function after the tablename because postgresql handles
queries of the form:

select t1.eval;
select t1.*;

Where eval can be a column of the t1 table or a function accepting
one opaque argument. The function is automatically passed each
row of t1. This is the important feature.

Andreas

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