* Tom Dunstan (pg...@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
Description: Digital signature