Re: Immodest Proposal: pg_catalog.pg_ddl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Fetter <david(at)fetter(dot)org>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Immodest Proposal: pg_catalog.pg_ddl
Date: 2005-12-14 15:01:47
Message-ID: 19245.1134572507@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Fetter <david(at)fetter(dot)org> writes:
> On Tue, Dec 13, 2005 at 11:33:20PM -0500, Tom Lane wrote:
>> and I don't even see the argument for doing it via a table rather
>> than via the postmaster log.

> Simple. Postmaster logs can roll over or otherwise be lost without
> damaging the DB. This would provide a non-volatile log of DDLs.

In that case you have to provide a pretty strong argument why everyone
should be forced to have a non-volatile log of DDLs. Or will there be
a way to turn it off? What about applications that, say, create and
delete tens of thousands of temp tables every day? What about security
issues (ie, who gets to read the log, or determine what gets into it)?
Is the log local to each database or global, and if local how do you
deal with DDL for shared objects (eg, tablespaces)? What features will
you provide for the inevitable need to truncate the log to keep its
space consumption within bounds?

I think the idea is pretty much a non-starter; it does little or nothing
that can't be done with the existing postmaster-log facility, and it
will add a whole lot of mechanism to do it. I also don't see why it
should be specifically tied to DDL. The idea of logging into a table
has come up before, but it's always been proposed in the form of putting
everything that goes to the postmaster log into a table. That seems to
me to be trying to build on the work we've already done, rather than
duplicating it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-12-14 15:06:33 Re: lo function changed in PostgreSQL 8.1.1
Previous Message Alvaro Herrera 2005-12-14 14:06:49 Re: Refactoring psql for backward-compatibility