Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <peter@2ndquadrant.com>
Cc: PG Hackers <pgsql-hackers@postgresql.org>
Date: 2012-02-21T01:50:58Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.

  2. Extend the parser location infrastructure to include a location field in

  3. Teach eval_const_expressions() to simplify an ArrayCoerceExpr to a constant

Peter Geoghegan <peter@2ndquadrant.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