On Tue, Nov 1, 2011 at 8:41 AM, Magnus Hagander <mag...@hagander.net> wrote: > On Tue, Nov 1, 2011 at 13:19, Simon Riggs <si...@2ndquadrant.com> wrote: >> On Mon, Oct 31, 2011 at 10:13 PM, Robert Haas <robertmh...@gmail.com> wrote: >>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander <mag...@hagander.net> >>> wrote: >>>> Actually, for the future, it might be useful to have a "state" column, >>>> that holds the idle/in transaction/running status, instead of the >>>> tools having to parse the query text to get that information... >>> >>> +1 for doing it this way. Splitting "current_query" into "query" and >>> "state" would be more elegant and easier to use all around. >> >> 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 be the backwards compatible way I suggested. > > That said, I think there's still value in exposing a "state" column, > and to encourage people not to rely on the text in the query column. > Then you can add it to your list of things to remove in 10.0 :-)
Personally, I think we're getting a bit overexcited about backward compatibility here. We make backward-incompatible changes in every release. Things that change the behavior of user queries (like reserving keywords, or other changes in syntax, or having the same syntax now mean something different) cause a fair amount of user pain, and we're justifiably cautious about making them. But changes that have to do with server administration, as far as I can see, result in much less pain. Splitting the current_query field into query and state is going to require only the most minimal adjustment to user code, and anyone for whom it's really a problem can easily create their own view that mimics the old behavior. On the flip side, keeping both fields around is going to make the pg_stat_activity, which is already extremely wide, even more difficult to read in a window of any reasonable width, especially because the field we're proposing to duplicate is the widest one by far. I also doubt very much that it creates a meaningful migration path; most people will just keep doing it the old way until it breaks, and even new users may not realize that one column is nominally deprecated. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers