On Dec 10, 2010, at 2:32 PM, Dimitri Fontaine wrote: > "David E. Wheeler" <da...@kineticode.com> writes: >> On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote: >>> I don't think we can safely design around one part version numbers here, >>> because I'm yet to see that happening in any extension I've had my hands >>> on, which means a few already, as you can imagine. >> >> Why not? Simplest thing, to my mind, is to have >> >> upgrade/foo-1.12.sql >> upgrade/foo-1.13.sql >> upgrade/foo-1.15.sql > > Since when is 1.12 a one part version number? :)
What difference does it make how many parts there are? If it's a naming convention, you just match /$extension-(.+?)\.sql$/. Simple. >> Since you know the existing version number, you just run all that come >> after. For example, if the current version is 1.12, then you know to >> run foo-1.13.sql and foo-1.15.sql. > > I don't think imposing what version numbers must look like and what the > separators in the file names should be is a good idea. The version numbers can be anything, so long as there *are* version numbers. And the rest of the file name should be just like the extension. > It's just moving the complexity from the rules for the user to obey to > having them explain us by which rules they're playing. I personally very > much prefer the later, as you can imagine. You keep making extension authors have to do more work. I keep trying to make it so they can do less. We want the barrier to be as low as possible, which means a lot of DRY. Make it *possible* to do more complicated things, but don't *require* it. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
