Tom Lane <t...@sss.pgh.pa.us> writes: > My feeling about this is that we should recommend that version > identifiers be limited to ASCII letters, digits, dots, and underscore, > but assume that extension authors are adults and can grasp the risks > of using other characters. We should not be in the business of trying > to force authors to write portable code whether they want to or not.
That's a reasonable view point too, and it's less work this way. I would have liked to be able to sort versions in SQL as a gain on this work, but well… > I think we've now converged on the agreement that we don't need to use > anything but equality checks. So it doesn't matter how the author > thinks the strings sort --- the upgrade scripts he provides define what > can follow what, and that's all we need to know. Check. > Well, you could look to see if there is a script that can update your > current version to something else. The existing pg_available_extensions > view needs to be rethought a bit, probably, but I'm not sure how. Maybe a SRF would do better here, returning the three columns step, from and to. The step is the order in which to read the rows. There would be some windowing or groups in the result set, but that should be ok. >> I can already hear people wanting version aliases instead. We could >> support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta' >> and maybe 'experimental'. Then rather than defining "current_version" >> authors would define any set of those keywords here, and CREATE >> EXTENSION and ALTER EXTENSION would by default only care for >> resp. 'stable' and 'support'. > > Hmm. That might be worth doing, but let's leave it for later when we > find out how much demand there really is. It does strike me that what > we ought to call the default-version parameter is just "default", since > that would fit in reasonably well with such an extension later. We could go as far as not requiring anything but considering any unknown parameter as a version alias, or setup a GUC placeholder so that the control file parsing is able to read version.defaut = '1.0' and others. Then we would just document what the default aliases are used by the commands CREATE EXTENSION and ALTER EXTENSION UPDATE TO. The big advantage of doing so is that it's then easy for extension authors to manage EOL. ALTER EXTENSION foo UPDATE; ERROR: there's no 'support' version available from version 1.2.3 Then you have to write ALTER EXTENSION foo UPDATE TO '2.0' or even UPDATE TO 'stable', and you realise it's a "major" upgrade, so you need to recheck the extension release notes etc. 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
