* Tom Dunstan (pgsql@tomd.cc) wrote:
> Extensions in contrib live in a weird place. Totally builtin stuff
> should obviously be dumped without versions, and stuff which is
> completely separate and follows its own release schedule should
> obviously be versioned. I guess we consider all modules in contrib to
> offer the same transparent upgrade guarantees as builtins, so they
> shouldn't be versioned, but it feels like some of them should be, if
> only because some aren't particularly tied in to the backend all that
> tightly. But I guess that's a bogus metric, the true metric is whether
> we want people to treat them as basically built-in, with the upgrade
> guarantees that go along with that.
Note that we don't actually make guarantees about either builtins or
contrib modules when it comes to major version upgrades. The current
way we package contrib and how we tie contrib releases to PG releases
means that we can get away with omitting the version and saying "well,
if you restore to the same PG major version then you'll get the same
contrib extension version, and if you restore into a different version
then obviously you want the version of contrib with that major
version" but that *only* works for contrib. We need to accept that
other extensions exist and that they aren't tied to PG major versions
nor to our release schedule. There's a lot more extensions out there
today which are *not* in contrib than there are ones which *are*.
Thanks,
Stephen
