From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Mark Hollomon <mhh(at)mindspring(dot)com>, hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP VIEW code question |
Date: | 2000-10-17 20:43:41 |
Message-ID: | 2219.971815421@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I don't know how it looks now, but the "DROP TABLE x, y, z" was pretty
> broken a while ago. For example, if there was some sort of dependency
> between the tables (foreign keys?) it would abort and leave an
> inconsistent state. I'm not very fond of this extension, but keep the
> issue in mind.
This is just a special case of the generic problem that you can't
roll back a DROP TABLE. That'll be fixed by 7.1, so I see no reason
not to allow the more convenient syntax.
BTW, Mark, the reason utility.c implements T_DropStmt with two loops
is presumably to try to avoid the rollback-drop-table problem; but it's
inherently bogus because not all error conditions can be checked there.
You could fold the two loops into one loop, and/or remove any checks
that are redundant with RemoveRelation itself.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nishad Prakash | 2000-10-17 20:51:09 | Re: UPPER and LOWER dosen't work correctly on special caracters (umlauts) |
Previous Message | Tom Lane | 2000-10-17 20:33:20 | Re: DROP VIEW code question |