Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas <hlinnaka@iki.fi> wrote: >> (Sorry if this was discussed already, I haven't been paying attention) >> >> LWLockAssign() is used by extensions. Are we OK with just breaking them, >> requiring them to change LWLockAssign() with the new mechanism, with #ifdefs >> to support multiple server versions? Seems like it shouldn't be too hard to >> keep LWLockAssign() around for the benefit of extensions, so it seems a bit >> inconsiderate to remove it.
> If there's a strong feeling that we should keep the old APIs around, > we can do that, but I think that (1) if we don't remove them now, we > probably never will and (2) they are vile APIs. Allocating the number > of add-in lwlocks that are requested or a minimum of 3 is just awful. > If somebody allocates a different number than they request it > sometimes works, except when combined with some other extension, when > it maybe doesn't work. This way, you ask for an LWLock under a given > name and then get it under that name, so if an extension does it > wrong, it is that extension that breaks rather than some other one. I > think that's enough benefit to justify requiring a small code change > on the part of extension authors that use LWLocks, but that's > obviously biased by my experience maintaining EDB's extensions, and > other people may well feel differently.
FWIW, I wasn't paying attention either, but I'm convinced by Robert's argument. Avoiding coupling between extensions is worth an API break.
I don't buy that, sorry.
New features, new APIs, very much agreed. Better API is a reason for new api, not a reason to remove old.
Old APIs - why can't we keep it? The change is minor, so it we can easily map old to new. Why choose to break all extensions that do this? We could easily keep this by making the old API assign locks out of a chunk called "Old Extension API". Deprecate the old API and remove in a later release. Like pretty much every other API we support.
We must respect that Extension authors need to support a number of our releases, meaning their job is already complex enough. We want to support people that write extensions, not throw obstacles in their path,
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
