Philip Warner <pjw@rhyme.com.au> writes:
> So long as the version is always in the first bytes of the struct, we are
> covered for compatibility.
Right ...
> I'd still argue for a PG_FUNCTION_API_V2 macro for the reasons above. What
> the fmgrs needs to do is:
> - call pg_fmgr_api_version() to get the protocol version
> - when it wants to call a function 'foo' see if there is a 'pg_api_foo'
> entry point, and if so, use the new interface, o/wise use the old one. No
> need to even call it.
This strikes me as completely backwards, because it prejudges an
assumption that protocol decisions can be made on a library-wide basis.
I see no need for a library-wide protocol definition. What I want to
do is call 'pg_api_foo' (if it exists) to find out all about the
function 'foo', without any restriction on whether 'foo' is like 'bar'
that happens to have been linked into the same shlib.
The test to see if 'pg_api_foo' exists is going to be the expensive
part of this anyway. Once you've done that, you may as well call it...
> My only real issue with all of this is that we need to separate the
> protocol selection from the the data exchange.
Negotiating a protocol to negotiate protocol strikes me as considerable
overkill. It should be plenty sufficient to say that a parameterless
function with a determinable name will hand back a struct whose first
word identifies the contents of the struct. Why do we need another
layer on top of that? Especially if it's a layer that makes the
unsupported assumption that all functions in a given shlib are similar?
That way reduces flexibility, rather than increasing it.
regards, tom lane
