On Sat, Mar 12, 2016 at 6:31 AM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 3/10/16 8:36 PM, Robert Haas wrote: >> >> 1. We make it true only for heavyweight lock waits, and false for >> other kinds of waits. That's pretty strange. >> 2. We make it true for all kinds of waits that we now know how to >> report. That still breaks compatibility. > > > I would absolutely vote for 2 here. You could even argue that it's a bug > fix, since those were waits we technically should have been indicating. > > The only way I can see #2 breaking anything is if you're using waiting=true > to determine whether you look at pg_locks and your code will blow up if you > get no rows back, but that seems like a pretty limited use case to me > (Hello, LEFT JOIN). > > Dropping the column entirely though would break tons of things.
That was a very good point I hadn't thought about. In that case, +1 to keep it. I also came to think of the renaming of pg_stat_activity.procpid -> pg_stat_activity.pid, which was renamed because "backwards compatibility was broken anyway" (due to current_query -> query). I wouldn't rule out there were users who didn't use the "current_query" column but *did* use "procpid", who wouldn't have been affected if the procpid column hadn't been renamed as well. Apparently in this case, it was OK to break even more things than necessary, since another things was already broken. I don't have any opinion whether doing so was a bad or good decision, it all depends on what the project's objectives are. Unfortunately, it feels like the case-by-case basis decision model lead to conflicting arguments, if they would be compared side-by-side. I really think the project need a policy here on how, why and when it's OK to break backwards-compatibility. Such a policy won't cover all cases of course, but if a consensus can be made on the basic principles, then discussion can be focused on the details and cases not covered by the basic principles, instead of "end up hashing it out on a case-by-case basis". -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
