Re: RFC tool to support development / operations work with slony replicated databases - Mailing list pgsql-general

From Andrew Hammond
Subject Re: RFC tool to support development / operations work with slony replicated databases
Date
Msg-id 1173206945.375137.89320@30g2000cwc.googlegroups.com
Whole thread Raw
In response to Re: RFC tool to support development / operations work with slony replicated databases  (Kenneth Downs <ken@secdat.com>)
List pgsql-general
On Mar 6, 5:44 am, k...@secdat.com (Kenneth Downs) wrote:
> Andrew Hammond wrote:
> > Each release will include a directory that has the same name as the
> > full release tag. This directory must contain all the scripts to be
> > applied.
>
> Have you considered using a data dictionary instead,

Data dictionary is a pretty generic term, could you please show me
what you mean by this?

> so that you can
> simply diff the structures and generate DDL to bring a database to its
> current state?

To fully express the semantics of a change, DDL is often interspersed
with DML. A trivial example is refactoring a table to reflect a 1 to n
relationship. In order to do this successfully, you must first execute
DDL to create a new table, then execute DML to pull data from the old
table into the new table, and finally execute DDL to remove the
columns in the old table as necessary.

> If your scripts contain data modification code, they can be preserved,
> but using a dictionary smooths over a lot of the quirkiness of the
> scripts-based approach.

Again, I'd be very interested in seeing what you mean by a dictionary.

Andrew


pgsql-general by date:

Previous
From: "Reuven M. Lerner"
Date:
Subject: Re: Database slowness -- my design, hardware, or both?
Next
From: "Andrej Ricnik-Bay"
Date:
Subject: Re: No buffer space available