Anssi Kääriäinen <anssi.kaariai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
