From: | Shane Ambler <pgsql(at)Sheeky(dot)Biz> |
---|---|
To: | David <wizzardx(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Database design: Backwards-compatible field addition |
Date: | 2008-06-18 19:15:38 |
Message-ID: | 48595EDA.9090604@Sheeky.Biz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David wrote:
> Hi list.
>
> If you have an existing table, and apps which use it, then how do you
> add new fields to the table (for new apps), but which might affect
> existing apps negatively?
>
If you know you are going to add a column then add it now and just not
have your app do anything with any data there.
Old apps don't know the new field4 exist and work as they did before it
was added. New apps work with data in field4 and apply default behaviour
when it is null.
The way that old apps get caught up in this scenario is when you use
SELECT * ... then loop through the index of columns returned.
The safe design for your apps is to use SELECT field1,field2,field3
FROM... giving your app a rigid data structure to work with, then either
loop through the column indexes or use column names to access the data
returned.
Of course dropping a column breaks old apps and you need to weigh up
these changes to decide whether app v1.x will continue to be usable or
must be upgraded for further use. Of course you can leave an old column
there for old apps and have new apps ignore it eg. remove it from SELECT
statements in the new app.
--
Shane Ambler
pgSQL (at) Sheeky (dot) Biz
Get Sheeky @ http://Sheeky.Biz
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Wilden | 2008-06-18 19:29:46 | Vacuum and inserts |
Previous Message | Sam Mason | 2008-06-18 18:49:20 | Re: Understanding fsync (was: Need Help Recovering from Botched Upgrade Attempt) |