Re: Tom Lane > > (The Debian regression tests remove plpgsql before testing all > > extensions in turn.) > > Meh. I think that's testing a case that we don't guarantee to work. > There was already a plpgsql dependency in hstore--1.1--1.2.sql, > which I just cribbed from to make these fixes.
The key difference is that hstore--1.1--1.2.sql was never required for installing an extension from scratch, only for upgrades. The practical relevance of this distinction is that the upgrade scripts are only run once, while install-time scripts (including the upgrade scripts for versions that do not have a direct creation script) are also required for dump-restore cycles. As an admin, I'd very much hate databases that couldn't be restored without extra fiddling. The thing that maybe saves us here is that while hstore is trusted, so any user can create it, plpgsql is trusted as well, but owned by postgres, so even database owners can't drop it from beneath hstore. Only superusers can "mess up" a database in that way. But still. > A band-aid sort of fix would be to roll up the base install scripts > for these modules to the latest version, so that a plain install from > scratch doesn't need to execute any of the catalog adjustments in > their update scripts. That's not terribly attractive from a maintenance > or testing standpoint, though. That's a pretty small price compared to the dump-reload inconsistencies. I can see the extra maintenance effort, but how many extensions would require rewriting as direct-install.sql scripts? I guess it's only a few that need plpgsql for upgrades. Christoph
