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

Re: DDL triggers?

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: David Fetter <david(at)fetter(dot)org>,SF Postgres <sfpug(at)postgresql(dot)org>
Subject: Re: DDL triggers?
Date: 2003-05-20 16:46:02
Message-ID: 200305200946.02742.josh@agliodbs.com (view raw or flat)
Thread:
Lists: sfpug
David,

> Roight.  In a more perfect world, people would do their DDL changes
> in some slightly more trackable way than the psql command line.
> Unfortunately, people sometimes don't.  What I'd like to do is make it
> so that tables, views, functions, &c have comments stuck on (inserted
> or appended, as appropriate) automagically.  These comments would be
> the DDL statement that did the deed.  I'm not so worried about DDL
> statements like DROP, but CREATE and ALTER would be very, very nice to
> be able to track.

This is the developers on the project, I take it?

What comes immediately to mind is simply taking away their rights to create 
objects in the public schema.   Then they'd have to e-mail their DDL 
statements to you.

Frankly, I've never done a project before where more than one person had admin 
rights on the database and did not go though an elaborate process of 
authorizing schema changes, i.e. "Proposed change to Items table: ALTER ... "

For automated tracking, there's the "after the fact" method:  pg_dump the 
schema to disk hourly and run a diff, saving the results to a log.  Or just 
version the complete schema file in CVS. Not quite what you want, but it 
could be automated.

Alternately, we can raise this on -Hackers and see what the difficulty would 
be for hacking some of the libraries to either:
1) save all DDL statements to a log, or:
2) back-up all tables, views, etc. to file before changing.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

sfpug by date

Next:From: David FetterDate: 2003-05-20 16:59:14
Subject: Re: DDL triggers?
Previous:From: David FetterDate: 2003-05-20 16:33:34
Subject: Re: DDL triggers?

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