Following this whole conversation rises the impression the topic is going to get lost in nirvana of personal preferences.
Most suggestions on change for itself are likely to not cross the border of "not justifying a compatibility break". I wonder, whether the actual point really is towards compatibility. On closer look this is more about a change in paradigm of "system tables". Seems like those previously had been crafted with having in mind more a human "reader" than a programmatic user. What seems to be requested sounds more like splitting access to system information into a level that is more appropriate for programmatic use (with all those basic properties being explicit) and some level more apt for being read. E.g. I much prefer reading an "<IDLE> in transaction" on a quick glance over having to search a column and recognize a "t" from an "f" to find out whether there is a transaction pending or not. So may be we need a (new) set of "tables/views" that provide detailed information that is designed for programmatic use as a basic interface layer. And reconstruct the existing "tables /views" based on those. That would allow all required changes to coexist without braking compatibility. And it also provides an easier ground for later "extensions" to such information. Anybody sticking with the existing interface will not suffer incompatibility. While anybody in need of more details and "better" information may switch over to the new basic layer. (And I doubt adding that "extra" level will cause problems performance wise...) Rainer Am 15.06.2011 06:19, schrieb Robert Haas: > On Tue, Jun 14, 2011 at 11:04 PM, Greg Sabino Mullane <g...@turnstep.com> > wrote: >>> For me, the litmus test is whether the change provides enough >>> improvement that it outweighs the disruption when the user runs into >>> it. >> For the procpid that started all of this, the clear answer is no. I'm >> surprised people seriously considered making this change. It's a >> historical accident: document and move on. > I agree with you on this one... > >>> This is why I suggested a specific, useful, and commonly requested >>> (to me at least) change to pg_stat_activity go along with this. >> +1. The procpid change is silly, but fixing the current_query field >> would be very useful. You don't know how many times my fingers >> have typed "WHERE current_query <> '<IDLE>'" > ...but I'm not even excited about this. *Maybe* it's worth adding > another column, but the problem with the existing system is *entirely* > cosmetic. The string chosen here is unconfusable with an actual > query, so we are talking here, as with the procpid -> pid proposal, > ONLY about saving a few keystrokes when writing queries. That is a > pretty thin justification for a compatibility break IMV. > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
