On Fri, Nov 4, 2011 at 9:48 AM, Magnus Hagander <mag...@hagander.net> wrote: > On Fri, Nov 4, 2011 at 14:42, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Marti Raudsepp <ma...@juffo.org> writes: >>> While we're already breaking everything, we could remove the "waiting" >>> column and use a state with value 'waiting' instead. >> >> -1 ... I think it's useful to see the underlying state as well as the >> waiting flag. Also, this would represent breakage of part of the API >> that doesn't need to be broken. > > I guess with the changes that showed different thing like fastpath, > that makes sense. But if we just mapped the states that are there > today straight off, is there any case where waiting can be true, when > we're either idle or idle in transaction? I think not..
Maybe if we get a sinval reset while we're just sitting there? Not sure. In any case, I agree with Tom. I think that most people will be happy to have a "query" column and a "state" column rather than a "current_query" column that amalgamates the two, but I see no reason to tinker with the waiting column if the changes we want to make don't otherwise require it. >>> Also, returning these as text seems a little lame. Should there be an >>> enum type for that? >> >> Perhaps, but we don't really use enum types in any other system views, >> so inventing one here would be out of character. > > Yeha, that seems inconsistent. Using a single character might work - > but it's not particularly user-friendly to do that in the view itself. +1 for keeping it as text, but loosing the angle brackets. -- 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
