Tom Lane wrote: > Well, the current ordering is definitely historical rather than > designed, but I'm hesitant to do more than minor tweaking. Even if we > think/hope it won't break applications, people are probably used to > seeing a particular ordering. > > I'm not necessarily dead set against it though. I guess if we were > to do what you suggest, we'd end up with > > identity: > datid | oid | > datname | name | > procpid | integer | > usesysid | oid | > usename | name | > application_name | text | > session: > client_addr | inet | > client_port | integer | > backend_start | timestamp with time zone | > transaction: > xact_start | timestamp with time zone | > query: > query_start | timestamp with time zone | > waiting | boolean | > current_query | text | > > or possibly that plus relocate procpid somewhere else. Anyone think > this is sufficiently better to justify possible confusion?
I think most reports have the stable information first, and the more dynamic information at the end, so reordering it this way does make sense. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
