| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, 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 13:49:40 |
| Message-ID: | 19002.1064929780@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> Since there's no performance difference at pg_dump time, I can't see any
>> advantage to freezing your decision then.
> I understand, and if everyone used pg_restore, then adding a flag to
> pg_restore to do this would make sense. However, everyone is used to
> treating that dump file as a simple dump and throwing it into psql.
So? A GUC variable could be set equally easily either way. In fact
more so.
> Psql doesn't have any special dump flags, so you have to do the
> environment variable trick,
You forgot SET ...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mike Mascari | 2003-09-30 13:54:43 | Re: Functional index performance question |
| Previous Message | Mike Leahy | 2003-09-30 13:26:19 | Divide by zero... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-09-30 13:58:01 | Re: ADD FOREIGN KEY (was Re: [GENERAL] 7.4Beta) |
| Previous Message | Tom Lane | 2003-09-30 13:46:52 | Re: more i18n/l10n issues |