Re: Isolation of schema renames

Ben Leslie <benno(at)benno(dot)id(dot)au> writes:
> I'm wondering if I can/should expect schema renames to be isolated.

Nope, you should not.

This is not an especially easy thing to fix, because to have the system
behave as you wish it did, your second transaction would have to be
ignoring already-committed DDL changes, and it is very easy to show
examples where that would be fatal. For example, consider

S1 S2

create table t (f1 int, f2 bigint);

begin;
insert into t values(42, 43); -- ok

begin;
alter table t add check (f1 < 100);
commit;

insert into t values(1000, 44); -- ok?

begin;
alter table t alter column f2 type int;
commit;

insert into t values(1, 100000000000); -- ok?
commit;

Now, in practice this specific example doesn't go through anyway, because
after its first insert, S2's transaction is holding a lock on t that
precludes the ALTER TABLE steps. But I only wrote it this way for
pedagogic purposes. If S2 had done some things but not touched t2 yet,
the concurrent ALTERs would succeed, and then S2 has no choice but to
respect the results of that DDL.

There are other ways we could define the results of this sort of thing,
but they generally would end up failing one or both of your transactions.
Letting it "just work" is not in the picture.

regards, tom lane