| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Groff, Dana" <Dana(dot)Groff(at)filetek(dot)com>, "Jan Wieck" <JanWieck(at)Yahoo(dot)com>, "Stephan Szabo" <sszabo(at)megazone23(dot)bigpanda(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Should this require CASCADE? |
| Date: | 2002-07-12 03:04:48 |
| Message-ID: | 6346.1026443088@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2002-07-12 03:04:54 | Re: Jan's Name (Was: Re: I am being interviewed by OReilly) |
| Previous Message | Alvaro Herrera | 2002-07-12 03:03:50 | Re: I am being interviewed by OReilly |