Robert Haas <robertmh...@gmail.com> writes:
> You could also argue that's a compatibility break, because people may
> have logic that assumes that a wait is always a heavyweight lock wait.
> If we keep the column but change the meaning, people who need to
> update their scripts may fail to notice. Hard breaks aren't that fun,
> but at least you don't fail to notice that something needs to be
> changed.
Yes. My recollection of the argument for the earlier renames of
pg_stat_activity columns is that it was basically the same thing:
we changed the semantics of these columns, you are very likely to
need to adjust your queries, so we'll change the column names to
make sure you notice. There's always a tradeoff there. Maybe you
won't need to adjust your queries, but maybe they'll break silently.
In this case I agree with the feeling that people probably took
waiting == true as an indication that there was a matching entry
in pg_locks, so the odds of subtle breakage if we keep the name
the same while changing the semantics are pretty high. Or we
could keep the semantics the same (waiting is true only for
heavyweight-lock waits) but that was mighty ugly too.
In short: we've already been over this territory, at length,
and I am not excited by people trying to bikeshed it again
after the fact, especially when no new arguments are being
presented. Can we call the discussion closed, please?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
