Re: Schema version control

From: Royce Ausburn <royce(dot)ml(at)inomial(dot)com>
To: Andy Colson <andy(at)squeakycode(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Schema version control
Date: 2011-02-11 03:08:25
Message-ID: C6E40F39-2656-4186-8F69-02E5E57623A7@inomial.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> So, 10.0 at 10057.
> 11.0 at 11023.
>
> then 10.1 needs some fixes so db is bumped to 10058.
>
> Then, later, you can upgrade 10057 to 11023, but you cant get 10058 to 11023.
>
> Humm... maybe you need smarter upgrade scripts? Would having logic in the script help? Something like:
>
> if not fieldExists('xyz) then alter table ... add xyz ...
>
>
>
> Or, maybe your schema numbering system is to broad? Maybe each table could have a version number?
>
>
> Or some kinda flags like:
> create table dbver(key text);
>
> then an update would be named: "add xyz to bob".
>
> then the update code:
>
> q = select key from dbver where key = 'add xyz to bob';
> if q.eof then
> alter table bob add xyz
>

This is effectively the approach we've been working with so far, but it isn't great. The issue is that you need to be really aware of what changes might or might not have been in the previous databases... This can be hard.

There's also the problem of updating data, etc.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Royce Ausburn 2011-02-11 03:09:44 Re: Schema version control
Previous Message Royce Ausburn 2011-02-11 03:06:17 Re: Schema version control