Re: Dependency / Constraint patch
От | Rod Taylor |
---|---|
Тема | Re: Dependency / Constraint patch |
Дата | |
Msg-id | 031001c21782$eda70ad0$fe01a8c0@jester обсуждение исходный текст |
Ответ на | Re: Dependency / Constraint patch ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Список | pgsql-patches |
> If you break out the following two patch items: > > > > - psql displays foreign keys (\d output) > > > - Foreign key triggers are autonamed based on the constraint name > > I'm sure that part of the patch will get committed (so long as it's good), > as we'd agreed already to come up with such a patch (except I never got Yes, isconstraint triggers are ignored. Triggers were easy to toss the names around as they inherit the name of the constraint. The constraint was autonamed. > > > - pg_dump uses ALTER TABLE / ADD FOREIGN KEY > > The item above is trouble because it makes adding foreign keys from dumps > very slow on large tables. The advantage of the CREATE CONSRAINT TRIGGER > approach is that it doesn't actually _check_ the constraint. > > My earlier suggestion was to create a 'SET CONSTRAINTS UNCHECKED;' sort of > transaction-only function that would make ADD FOREIGN KEY _not_ check > constraints. I can't remember what the repsonse to that was, but we need > something... No choice. Using CREATE TRIGGER drops all dependency information with a pgdump / restore -- not to mention the actual foreign key. If you want to wrap it with the above suggestion feel free. I've got a few other things to clean up before I could go into that.
В списке pgsql-patches по дате отправления: