> On Nov 16, 2021, at 7:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Mark Dilger <mark.dil...@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 could appear, and old gucs
disappear. That seems analogous to new functions appearing and old functions
disappearing. If you upgrade (not downgrade) the .so, the new gucs and
functions will be in the .so, but won't be callable/grantable from sql until
the upgrade script runs. The old gucs and functions will be missing from the
.so, and attempts to call them/grant them from sql before the upgrade will
fail. What am I missing here?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
