| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lamar Owen | 2000-03-08 21:15:40 | Re: [HACKERS] DROP TABLE inside a transaction block |
| Previous Message | Tom Lane | 2000-03-08 19:54:23 | Re: [HACKERS] Transaction abortions & recovery handling |