BUFFER_LOCK_* synonyms

On 2015-09-16 08:31:48 -0700, Jeff Janes wrote:

All of the index methods have their own synonyms of the BUFFER_LOCK_*
constants, for example:

#define GIN_SHARE BUFFER_LOCK_SHARE
#define GIST_SHARE BUFFER_LOCK_SHARE
#define HASH_READ BUFFER_LOCK_SHARE
#define BT_READ BUFFER_LOCK_SHARE

But most of them pass their constants directly to LockBuffer. So if they
were ever defined to be anything else, things would fall apart pretty
comprehensively. (Hash index also passes them to LockBuffer, but only
indirectly via some utility functions).

What does this pseudo-encapsulation get us? It seems like we have a
separation of spelling, but no real separation of concerns.

I was annoyed by this more than once too. It also bugs me that unlocking
a buffer is spelled LockBuffer(..., BUFFER_LOCK_UNLOCK) - that just
reads wrong.

FWIW, I think LockBuffer() as a extern C function is a pretty bad idea too -
it's full of essentially unpredictable branches which on the caller's
side are all constant.

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Sep 16, 2015 at 9:30 AM, Andres Freund <andres@anarazel.de> wrote:

I was annoyed by this more than once too. It also bugs me that unlocking
a buffer is spelled LockBuffer(..., BUFFER_LOCK_UNLOCK) - that just
reads wrong.

Pretty sure that this was discussed a couple of times before. I find
it annoying myself, but I tend to doubt that it's worth changing.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers