Skip site navigation (1) Skip section navigation (2)

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: Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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-03-27 19:26:55
Message-ID: 24810.1332876415@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
> I've attached a patch with the required modifications.

I've committed the core-backend parts of this, just to get them out of
the way.  Have yet to look at the pg_stat_statements code itself.

> I restored the location field to the ParamCoerceHook signature, but
> the removal of code to modify the param location remains (again, not
> because I need it, but because I happen to think that it ought to be
> consistent with Const).

I ended up choosing not to apply that bit.  I remain of the opinion that
this behavior is fundamentally inconsistent with the general rules for
assigning parse locations to analyzed constructs, and I see no reason to
propagate that inconsistency further than we absolutely have to.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Peter GeogheganDate: 2012-03-27 19:47:38
Subject: Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)
Previous:From: Robert HaasDate: 2012-03-27 19:23:04
Subject: Re: Patch: add timing of buffer I/O requests

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group