Re: DROP VIEW code question

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

In response to

Browse pgsql-hackers by date

  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