Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] DROP TABLE inside a transaction block

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mike Mascari <mascarm(at)mascari(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Date: 2000-03-08 20:12:38
Message-ID: Pine.BSF.4.21.0003081607320.591-100000@thelab.hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, 8 Mar 2000, Bruce Momjian wrote:

> > But with Postgres, we can write a utility to do this for us, so I
> > think that it isn't so much of an issue. In fact, perhaps we could
> > have a backend function which could do this, so we could query the
> > sizes directly.
> 
> Does not work if the table was accidentally deleted.  Also requires the
> backend to be running.

For ppl that aim ourselves at providing for data integrity, we sure have a
lot of "if the table was accidentally deleted" problems with poor
solutions, no? :)  

IMHO, we are basically supporting ppl *not* doing regular backups of their
data ... most, if not all, of the problems that ppl feel exist that
requires the use of 'flat files', IMHO, aren't big problems if properly
backup procedures are followed ...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy(at)hub(dot)org           secondary: scrappy(at){freebsd|postgresql}.org 


In response to

Responses

pgsql-hackers by date

Next:From: Lamar OwenDate: 2000-03-08 21:15:40
Subject: Re: [HACKERS] DROP TABLE inside a transaction block
Previous:From: Tom LaneDate: 2000-03-08 19:54:23
Subject: Re: [HACKERS] Transaction abortions & recovery handling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group