Mark Dilger <mark.dil...@enterprisedb.com> writes:
> 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.
True, but in general users might not care about getting access to new
features (or at least, they might not care until much later, at which
point they'd bother to run ALTER EXTENSION UPDATE).
> 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?
Here, you are describing behavior that's against project policy and would
be rejected immediately if anyone submitted a patch that made an extension
do that. Newer .so versions are expected to run successfully, not fail,
with an older version of their SQL objects. Were this not so, it's almost
inevitable that a binary upgrade would fail, because the extension is
likely to be called into action somewhere before there is any opportunity
to issue ALTER EXTENSION UPDATE. Even in-place updates of extensions
would become problematic: you can't assume that a rollout of new
executables will be instantly followed by ALTER EXTENSION UPDATE.
Basically, I think the proposed new system catalog is both unworkable
and entirely unnecessary. Maybe it would have been okay if Peter had
designed GUCs like that a couple of decades ago, but at this point
we have a ton of infrastructure --- much of it not under the core
project's control --- that assumes that GUCs can be created with just
a bit of code. I do not think that this feature is worth the cost of
changing that. Or IOW: ALTER SYSTEM SET has gotten along fine without
such a catalog; why can't this feature?
I also notice that the patch seems to intend to introduce tracking
of which user "owns" a GUC, which I think is even more unworkable.
They are all going to wind up owned by the bootstrap superuser
(extension GUCs too), so why bother?
regards, tom lane
