Bruce Momjian <pgman@candle.pha.pa.us> writes:
> coming from 7.2 is going to cause problems in 7.3, i.e. do we make
> assumptions that dependency info is there and in cases it isn't, are
> there surprises for users, where things worked fine in 7.2. I want to
> know if there are cases where we assumed dependency info was there when
> in 7.2 we handled the lack of depenency better.
No, we have not broken any cases that used to work, AFAIK.
There are new features in 7.3 that will not work in a database made from
a 7.2 dump --- for example, dropping an old table containing a serial
column won't make the sequence go away, because we won't have a
dependency link between the table and the sequence. But it didn't go
away in 7.2 either, so the behavior's no worse. Another thing we won't
understand is that certain sets of triggers make up a foreign-key
constraint, so you won't be able to use ALTER TABLE DROP CONSTRAINT to
delete 'em. But you couldn't in 7.2 either.
While I've toyed with the notion of trying to intuit these dependencies
as we reload a database, I'm not at all sure it's a good idea. The
former 7.2 user might be quite unhappy if we drop a sequence he wasn't
expecting to have dropped. We cannot tell for certain how the sequence
was made --- it might have been handmade and then used in an explicit
DEFAULT expression, in which case an auto-drop dependency would probably
not be a friendly thing to spring on the user.
The bulk of the new dependencies are made automatically as we handle
CREATE statements, so they'll be correct in a reloaded database anyway.
AFAIR it's just serial sequences and foreign keys that are not going to
be as bright as they might be.
regards, tom lane
