Anssi Kääriäinen <anssi.kaariainen@thl.fi> writes:
> upgrade_from_2.0.sql contents:
> alter table foobar add column id3 integer;
> pg_execute_extension_file('upgrade_from_3.0.sql');
>
> ...
>
> So, when creating a new version you would need to update the main .sql file,
> create a new upgrade file, and alter the upgrade_from_previous_version.sql
> to include the new upgrade file. This should be relatively easy to
> maintain. Also, this would give you the freedom to not chain the files when
> that is not appropriate.
Again, why not, I think I can see how this would work out. What I don't
see is what is the gain compared to preparing the right files at make
time and only shipping "autonomous" files. I very much prefer to handle
a set of source SQL files and some cat a b c > ship.sql rules rather
than ship loads of files that all depends on each other.
> By the way, I saw that the character '.' is not allowed in the xxx part of
> upgrade_from_xxx and this is not documented in the patch. What can be in the
> xxx part, and is this documented somewhere else?
It has to be a valid configuration variable name, as any other GUC, and
it's not a placeholder (only those can contain dots). We're using the
same parser as for postgresql.conf and recovery.conf here. Not sure
where that is documented, though.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support