Re: [PATCH] optional cleaning queries stored in pg_stat_statements - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [PATCH] optional cleaning queries stored in pg_stat_statements
Date
Msg-id 4EB7FD49.8050009@2ndQuadrant.com
Whole thread Raw
In response to Re: [PATCH] optional cleaning queries stored in pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11/06/2011 06:00 PM, Tom Lane wrote:
> Peter Geoghegan<peter@2ndquadrant.com>  writes:
>
> >  A major consideration was backwards compatibility;
> This is not a consideration that the community is likely to weigh
> heavily, or indeed at all.  We aren't going to back-port this feature
> into prior release branches, and we aren't going to want to contort its
> definition to make that easier.

Being able to ship a better pg_stat_statements that can run against 
earlier versions as an extension has significant value to the 
community.  Needing to parse log files to do statement profiling is a 
major advocacy issue for PostgreSQL.  If we can get something useful 
that's possible to test as an extension earlier than the 9.2 
release--and make it available to more people running older versions 
too--that has some real value to users, and for early production testing 
of what will go into 9.2.

The point where this crosses over to requiring server-side code to 
operate at all is obviously a deal breaker on that idea.  So far that 
line hasn't been crossed, and we're trying to stage testing against 
older versions on real-world queries.  As long as it's possible to keep 
that goal without making the code more difficult to deal with, I 
wouldn't dismiss that as a useless distinction.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: git trunk doesn't build
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] optional cleaning queries stored in pg_stat_statements