Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Date: 2012-02-21 01:50:58
Message-ID: 22052.1329789058@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> Another look around shows that the CoerceToDomain struct takes its
> location from the new Const location in turn, so my dirty little hack
> will break the location of the CoerceToDomain struct, giving an
> arguably incorrect caret position in some error messages. It would
> suit me if MyCoerceToDomain->arg (or the "arg" of a similar node
> related to coercion, like CoerceViaIO) pointed to a Const node with,
> potentially, and certainly in the case of my original CoerceToDomain
> test case, a distinct location to the coercion node itself.

Sorry, I'm not following. What about that isn't true already?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maxim Boguk 2012-02-21 01:57:34 Re: Unfamous 'could not read block ... in file "...": read only 0 of 8192 bytes' again
Previous Message Tom Lane 2012-02-21 01:48:30 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)