Robert Haas <robertmh...@gmail.com> writes: > On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas <hlinn...@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. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers