Add syntax position field to Vars?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Add syntax position field to Vars?
Date: 2006-04-28 22:22:26
Message-ID: 18105.1146262946@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-04-28 22:54:59 Re: Solaris ASM problem
Previous Message Theo Schlossnagle 2006-04-28 21:50:42 Re: Solaris ASM problem