| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, Peter Childs <Blue(dot)Dragon(at)blueyonder(dot)co(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
| Date: | 2003-09-30 00:48:25 |
| Message-ID: | 13819.1064882905@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> I think I can accept it to be the choice of the DBA what to do. Pg_dump
> has that kind of options already, one can choose between COPY and INSERT
> for example. Why not adding the choice of dumping FKeys as ALTER TABLE
> or CREATE CONSTRAINT TRIGGER?
We don't want it dumping as CREATE CONSTRAINT TRIGGER, because (a) that
loses pg_depend information and (b) it's too low-level a representation;
we couldn't ever change the implementation of foreign keys as long as
dumps look like that.
Also, I don't see why you'd want to make such a choice at pg_dump time.
Probably better to control it at restore time. Accordingly, my proposal
if we were to go that route would be a boolean GUC variable that simply
prevents ALTER TABLE ADD FOREIGN KEY from doing the validity checks.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Wieck | 2003-09-30 00:55:05 | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
| Previous Message | Stephan Szabo | 2003-09-30 00:40:47 | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-09-30 00:51:58 | Re: ERROR: "foo_type" is a composite type |
| Previous Message | Stephan Szabo | 2003-09-30 00:40:47 | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |