> I ran into this when I was
> working on GetNamedDSA() and GetNamedDSHash()
Thanks for mentioning these, I didn't notice them when I rebased on
the master branch. One of my use cases was this, I implemented
something similar to GetNamedDSHash - it's a generic wrapper for
dshash in C++, and I ran into the same issue.
> Besides the lwlock name, I can see someone
> wanting to pass some other initialization info that may vary
> depending on extension GUCs, etc.
Yes, that was my thought too. GUCs/globals can be accessed directly,
but there's still the reusing the same function part. and also
calculated local variables.
My other use case is using GetNamedDSMSegment without DSHash, with a
flexible array, similar to:
struct Foo {
LWLock lock;
size_t size;
Bar data[];
};
* To create a few of these, I have to provide a lock name to the
callback, that's the "reusing the same callback" part again
* And then there's the question of initialization. Either I leave it
to the caller after returning from GetNamedDSHash using the lock, or
somehow I have to tell the initialization callback the array size -
even if I can calculate the size based on a GUC, I wouldn't want to
trust that instead of the actual information from the caller.
> Well, for one, it requires all existing extensions that use
> GetNamedDSMSegment() to be updated. That might not be too terrible, but in
> any case, I think we need a stronger reason than the simplicity of the
> implementation to do something.
I did some searching for usage before my initial email, and I only
found 3 extensions that use this method, which seemed like a small
number. Also, the LWLockInitialize change already requires ifdefs in
this function for PG19.
But maybe the second use case alone is too specific to justify this
change, and there are workarounds to it.
