> On Nov 16, 2021, at 7:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> I don't think we support using a .so that is mismatched against the
>> version of the extension that is installed.
>
> You are entirely mistaken. That's not only "supported", it's *required*.
> Consider binary upgrades, where the SQL objects are transferred as-is
> but the receiving installation may have a different (hopefully newer)
> version of the .so. That .so has to cope with the older SQL object
> definitions; it doesn't get to assume that the upgrade script has been
> run yet.
You are talking about mismatches in the other direction, aren't you? I was responding to Robert's point that new gucs
couldappear, and old gucs disappear. That seems analogous to new functions appearing and old functions disappearing.
Ifyou upgrade (not downgrade) the .so, the new gucs and functions will be in the .so, but won't be callable/grantable
fromsql until the upgrade script runs. The old gucs and functions will be missing from the .so, and attempts to call
them/grantthem from sql before the upgrade will fail. What am I missing here?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
