Greg Smith wrote: > On 06/14/2011 06:00 PM, Tom Lane wrote: > > As far as Greg's proposal is concerned, I don't see how a proposed > > addition of two columns would justify renaming an existing column. > > Additions should not break any sanely-implemented application, but > > renamings certainly will. > > > > It's not so much justification as something that makes the inevitable > complaints easier to stomach, in terms of not leaving a really bad taste > in the user's mouth. My thinking is that if we're going to mess with > pg_stat_activity in a way that breaks something, I'd like to see it > completely refactored for better usability in the process. If code > breaks and the resulting investigation by the admin highlights something > new, that offsets some of the bad user experience resulting from the > breakage. > > Also, I haven't fully worked whether it makes sense to really change > what current_query means if the idle/transaction component of it gets > moved to another column. Would it be better to set current_query to > null if you are idle, rather than the way it's currently overloaded with > text in that case? I don't like the way this view works at all, but I'm > not sure the best way to change it. Just changing procpid wouldn't be > the only thing on the list though.
Agreed on moving '<IDLE>' and '<IDLE> in transaction' into separate fields. If I had thought of it I would have done it that way years ago. (At least I think it was me.) Using angle brackets to put magic values in that field was clearly wrong. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
