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

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:47:38
Message-ID: CAEYLb_XH0n6o1fstQjsEDDQ2dD3hsybTEKj1SfmZ5QrcqZLs5Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 March 2012 20:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Thanks. I'm glad that we have that out of the way.

> 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.

Fair enough.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-03-27 20:05:08 Re: Command Triggers patch v18
Previous Message Tom Lane 2012-03-27 19:26:55 Re: Re: pg_stat_statements normalisation without invasive changes to the parser (was: Next steps on pg_stat_statements normalisation)