| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannu Krosing <hannu(at)tm(dot)ee> |
| Cc: | Alvaro Herrera <alvherre(at)atentus(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: DROP TABLE... CASCADE weirdness |
| Date: | 2002-09-14 14:43:53 |
| Message-ID: | 26034.1032014633@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hannu Krosing <hannu(at)tm(dot)ee> writes:
> This seems to be a problem that is of similar nature to our UNIQUE
> constraints not working in all cases (depending on the _physical_ order
> of tuples, which should never affect any user-visible behaviour).
No, I don't see any similarity at all. The behavior Alvaro is unhappy
with is perfectly deterministic and repeatable. He's basically saying
that DROP should be forgiving of redundant DROP operations, so long as
they are packaged into a single command. I don't really agree with
that, but it doesn't seem related to the UNIQUE issues.
> The two DROP TABLE cases are not equivalent in the sense that the first
> is _one_ command and the other is _two_ separate commands.
As long as they are wrapped into a single transaction block, there is no
difference.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-09-14 15:14:23 | Re: Multicolumn foreign keys need useless unique indices? |
| Previous Message | Hannu Krosing | 2002-09-14 09:54:06 | Re: DROP TABLE... CASCADE weirdness |