Phil Sorber <p...@omniti.com> writes:
> I compiled 9.1 stable head and tested it out. You are correct my
> example no longer works there because of the patch that stopped the
> auto-generated types from becoming dependencies of the extension. In
> fact, the cascade no longer works even if I don't remove the table or
> sequence from the extension. And I agree with your assertions here
> that allowing the extension authors to be adults is fine. However, I
> don't think leaving the database in a bad state is acceptable.
My initial reaction was that this wouldn't be worth the trouble, but
on reflection it occurred to me that the case can still be produced in
HEAD without anything as obviously bogus as dropping the script's own
extension. For instance, suppose the upgrade script in your example
attempts to add the rowtype to the extension explicitly:
alter extension bug_example add type table_a;
alter extension bug_example drop table table_a;
alter extension bug_example drop sequence table_a_id_seq;
drop table table_a cascade;
create table table_b ( id serial, primary key (id) );
With this script, the failure naturally will occur just the same way
in HEAD, since the extension will get dropped due to CASCADE and then
the CREATE TABLE step will add a pg_depend entry referencing the
already-dropped extension.
This is still a bit improbable, but it demonstrates that non-obvious
mistakes in dependency management could lead to the situation happening,
so it convinces me that it's worth expending a little bit of code to
prevent it. Fortunately it's quite trivial to do: we can just make
RemoveExtensionById refuse to delete the extension if its OID is equal
to the CurrentExtensionObject state variable. Committed at
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=871dd024a6adf7766702b1cdacfb02bd8002d2bb
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
