Re: proposal - get_extension_version function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal - get_extension_version function
Date
Msg-id 256978.1678315405@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal - get_extension_version function  (Jacob Champion <jchampion@timescale.com>)
Responses Re: proposal - get_extension_version function  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Jacob Champion <jchampion@timescale.com> writes:
> What I'm trying to pin down is the project's position on the reverse
> -- binary version X and SQL version X+1 -- because that seems
> generally unmaintainable, and I don't understand why an author would
> pay that tax if they could just avoid it by bailing out entirely. (If
> an author wants to allow that, great, but does everyone have to?)

Hard to say.  Our experience with the standard contrib modules is that
it really isn't much additional trouble; but perhaps more-complex modules
would have more interdependencies between functions.  In any case,
I fail to see the need for basing things on a catalog lookup rather
than embedding API version numbers in relevant C symbols.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Matthias van de Meent
Date:
Subject: Re: Ignoring BRIN for HOT updates (was: -udpates seems broken)
Next
From: Jacob Champion
Date:
Subject: Re: postgres_fdw, dblink, and CREATE SUBSCRIPTION security