On Fri, 2011-02-11 at 08:35 -0500, Daniel Popowich wrote:
> think no software process can make anyone happy. It's a human
> process: declare someone the owner of the database schema, let them
> own the long term development of the schema, and if anyone needs a
> change, they have to communicat
> What about upgrades that can't be derived directly from an inspection
> of the schema? Some examples:
>
> - Adding a NOT NULL constraint (without adding a DEFAULT). You often
> want to precede this with filling in any existing NULL values, so the
> new constraint doesn't fail.
This is an imp
Hello Benjamin,
On Wed, 2010-08-18 at 16:32 -0700, Benjamin Smith wrote:
> Is there a way to update a number of databases hosted on a single server
> without opening a separate psql connection to each database?
I believe you are more interested in applying an atomic update for all
databases rat
This example is certainly a workable situation. However it does require
understanding the constraints of an ALTER TABLE statement and manually
developing appropriate scripts.
The update model offered my ChronicDB accounts for schema changes of
considerable complexity, such as merging fields, parti
Jeff,
One way to address the indefinite locking due to an ALTER TABLE
statement for PostgreSQL is to use ChronicDB. It allows you to apply
such a schema change live, without bringing down the database.
The space requirements for applying the live schema change would be to
have at least twice as m
b.com/request_new_features
Sincerely,
ChronicDB Community Team
http://chronicdb.com/benefits_of_chronicdb
