On Thu, Feb 03, 2011 at 10:21:28AM +0200, Anssi Kääriäinen wrote:
> On 02/02/2011 08:22 PM, Dimitri Fontaine wrote:
>> Either one line in the Makefile or a new file with the \i equivalent
>> lines, that would maybe look like:
>>
>> SELECT pg_execute_sql_file('upgrade.v14.sql');
>> SELECT pg_execute_sql_file('upgrade.v15.sql');
>>
>> So well… I don't see how you've made it less gross here.
> Chaining the upgrade files should be relatively easy, if something like
> pg_execute_sql_file would be available (actually it would need to be
> pg_execute_extension_file so that @extschema@ would be substituted
> correctly).
>
> 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.
The advantage of this is that it keeps the logic for mapping version
to upgrades in the config: the upgrade scripts mearly handle the actual
SQL for doing a specific task, not a collection of tasks only related by
virtue of being released at the same time.
Ross
--
Ross Reedstrom, Ph.D. reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist phone: 713-348-6166
Connexions http://cnx.org fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
