I was looking at what it'd take to handle attaching an error cursor
to the message about "column "foo" must appear in the GROUP BY clause or
be used in an aggregate function", as per recent discussion here:
http://archives.postgresql.org/pgsql-sql/2006-04/msg00206.php
While we've now got the parser infrastructure needed to point at
bogus variable references, this particular message doesn't come out
until long after the raw ColumnRef node has been converted to a Var.
So it seems the only reasonable way to do it would be to include
the "token location" field in the Var node type.
My original vision of the token-location mechanism was that the location
info would only be present in the raw parser output nodes, and no extra
overhead would be added to the representations used by stored rules,
planning, and execution. I'm a tad annoyed by the idea of carrying
along a field to store something that won't be of any value after the
parsing stage. On the other hand, it's not *that* much overhead, and
there are a number of confusing messages like this one that would
probably benefit from having an error cursor attached.
If we did this I'd be inclined to add it to Params too, as I already
noted a few places where it'd be really nice to point at the Param
we're complaining about.
Any opinions whether to do it or not?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
