On Thu, Feb 3, 2011 at 9:53 AM, Ross J. Reedstrom <reeds...@rice.edu> wrote: >> Example: >> >> upgrade_from_1_0 = '1.0 => upgrade_from_1.0.sql' >> upgrade_from_2_0 = '2.0 => upgrade_from_2.0.sql' >> upgrade_from_3_0 = '3.0 => upgrade_from_3.0.sql' > > Hmm, how about allowing a list of files to execute? That allows the > developer to create modularized sql, and composite it in the config: > > for a mythical version 4.0: > > 1.0 => add_foobar_table.sql new_method_baz.sql > 2.0 => drop_method_baz.sql add_quuz_table.sql > # oops, we still needed this > 3.0 => new_method_baz.sql > > I know when I'm developing such upgrades, the code looks like that, > until I need to shoehorn them into the upgrade systems idea of version > numbers matching names to find scripts to run.
Good idea. My code looks that way too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
