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
