On Tue, Nov 01, 2011 at 10:13:52AM -0400, Andrew Dunstan wrote:
>
>
> On 11/01/2011 09:52 AM, Tom Lane wrote:
> >Simon Riggs<simon@2ndQuadrant.com> writes:
> >>Why not leave it exactly as it is, and add a previous_query column?
> >>That gives you exactly what you need without breaking anything.
> >That would cost twice as much shared memory for query strings, and twice
> >as much time to update the strings, for what seems pretty marginal
> >value. I'm for just redefining the query field as "current or last
> >query".
>
> +1
>
> >I could go either way on whether to rename it.
>
> Rename it please. "current_query" will just be wrong. I'd be
> inclined just to call it "query" or "query_string" and leave it to
> the docs to define the exact semantics.
+1 on providing the most-recent-query info
+1 on the state/query split as a means
+1 rename from current_query (i.e. break it)
personalbikeshedcolor: query_string
Personal opinion on "backwards compatability" matches Robert's: things
that affect admin functionality are less of an issue than those that
impact user (i.e. coder) SQL. And definitely break it: I may chose to fix
it by bodging in a view for the old behavior myself, but that's
my choice. Perhaps provide an example view def in change notes if you
really want to. For myself, when making fixes to monitor scripts for
this type of change, my reaction is probably "Yes, finally, I'm not
regexing on the d*mn query string anymore!"
Ross
P.S. though apparently it doesn't bother me enough to create and submit
a patch myself. :-(
--
Ross Reedstrom, Ph.D. reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
Connexions http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
