Re: Should this require CASCADE?
| От | Tom Lane |
|---|---|
| Тема | Re: Should this require CASCADE? |
| Дата | |
| Msg-id | 6346.1026443088@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Should this require CASCADE? ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
| Ответы |
Re: Should this require CASCADE?
Re: Should this require CASCADE? |
| Список | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> With all this dependency stuff, what happens with the ALTER TABLE / DROP NOT
> NULL syntax we came up with?
Nothing, AFAICS. NOT NULL doesn't have any dependency implications.
> Also, when talking about whether or not the index supporting a constraint
> should be sort of 'hidden' from the user, should not we change pg_dump to
> dump unique indices using the ALTER TABLE syntax, rather than the CREATE
> UNIQUE INDEX syntax? Otherwise this information will be lost.
I thought we did that already. We do need to tweak pg_dump's handling
of foreign keys though --- dumping some trigger definitions is no longer
the right thing.
It would be interesting to see if we can reasonably reverse-engineer
a foreign-key-constraint structure given the CREATE TRIGGER commands
that are actually going to be present in existing pg_dump scripts.
regards, tom lane
В списке pgsql-hackers по дате отправления: