Thread: why two dashes in extension load files
Why do the extension load files need two dashes, like xml2--1.0.sql? Why isn't one enough?
Peter Eisentraut <peter_e@gmx.net> writes: > Why do the extension load files need two dashes, like xml2--1.0.sql? > Why isn't one enough? Because we'd have to forbid dashes in extension name and version strings. This was judged to be a less annoying solution. See yesterday's discussion. regards, tom lane
On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Why do the extension load files need two dashes, like xml2--1.0.sql? > > Why isn't one enough? > > Because we'd have to forbid dashes in extension name and version > strings. This was judged to be a less annoying solution. See > yesterday's discussion. I'm not convinced. There was nothing in that discussion why any particular character would have to be allowed in a version number. I'd propose that dashes should be prohibited in version names anyway, because downstream packaging will want to use that to separate packaging revisions. It might be better to discuss that explicitly rather than hiding it in some thread of another title. Other comments?
Peter Eisentraut <peter_e@gmx.net> writes: > On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote: >> Peter Eisentraut <peter_e@gmx.net> writes: >>> Why do the extension load files need two dashes, like xml2--1.0.sql? >>> Why isn't one enough? >> Because we'd have to forbid dashes in extension name and version >> strings. This was judged to be a less annoying solution. See >> yesterday's discussion. > I'm not convinced. There was nothing in that discussion why any > particular character would have to be allowed in a version number. Well, there's already a counterexample in the current contrib stuff: uuid-ossp. We could rename that to uuid_ossp of course, but it's not clear to me that there's consensus for forbidding dashes here. regards, tom lane
On Mon, Feb 14, 2011 at 6:49 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote: >> Peter Eisentraut <peter_e@gmx.net> writes: >> > Why do the extension load files need two dashes, like xml2--1.0.sql? >> > Why isn't one enough? >> >> Because we'd have to forbid dashes in extension name and version >> strings. This was judged to be a less annoying solution. See >> yesterday's discussion. > > I'm not convinced. There was nothing in that discussion why any > particular character would have to be allowed in a version number. I'd > propose that dashes should be prohibited in version names anyway, > because downstream packaging will want to use that to separate packaging > revisions. It might be better to discuss that explicitly rather than > hiding it in some thread of another title. I think the question is more - what do we disallow in package name? Eg. Debian disallows '_' and uses it as magic separator. It works, but it not as obvious as '-' vs '--', and '--' allows both '_' and '-' in package name. Unlikely anyone will want '--' in package name. I would vote for current '--' and keeping version name simple, no '_' and '-' there. As we want to do some logic on that. -- marko
On Feb 14, 2011, at 8:54 AM, Tom Lane wrote: >> I'm not convinced. There was nothing in that discussion why any >> particular character would have to be allowed in a version number. > > Well, there's already a counterexample in the current contrib stuff: > uuid-ossp. We could rename that to uuid_ossp of course, but it's > not clear to me that there's consensus for forbidding dashes here. I'd be fine if commas were used instead. Best, David
"David E. Wheeler" <david@kineticode.com> writes: > On Feb 14, 2011, at 8:54 AM, Tom Lane wrote: >>> I'm not convinced. There was nothing in that discussion why any >>> particular character would have to be allowed in a version number. >> Well, there's already a counterexample in the current contrib stuff: >> uuid-ossp. We could rename that to uuid_ossp of course, but it's >> not clear to me that there's consensus for forbidding dashes here. > I'd be fine if commas were used instead. Commas do not seem like an improvement to me at all --- they are widely used as list separators. I guess the real question is what's Peter's concrete objection to the double-dash method? regards, tom lane
On Feb 14, 2011, at 9:14 AM, Tom Lane wrote: > Commas do not seem like an improvement to me at all --- they are widely > used as list separators. Fair enough. > I guess the real question is what's Peter's concrete objection to the > double-dash method? Hey, I know, a double-dash between the extension name and first version, and -> between the first and second version: foo--1.2->1.4.sql ;-P David
2011/2/14 Tom Lane <tgl@sss.pgh.pa.us>: > "David E. Wheeler" <david@kineticode.com> writes: >> On Feb 14, 2011, at 8:54 AM, Tom Lane wrote: >>>> I'm not convinced. There was nothing in that discussion why any >>>> particular character would have to be allowed in a version number. > >>> Well, there's already a counterexample in the current contrib stuff: >>> uuid-ossp. We could rename that to uuid_ossp of course, but it's >>> not clear to me that there's consensus for forbidding dashes here. why do we care if there is a dash in the middle of a text where there are no numbers ? > >> I'd be fine if commas were used instead. > > Commas do not seem like an improvement to me at all --- they are widely > used as list separators. > > I guess the real question is what's Peter's concrete objection to the > double-dash method? I have to admit that I am a bit surprised by this -- stuff too. An objection might be completely non-technical, but advocacy : "what this funny new name convention those PostgreSQL folks did invent ?!" -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
Cédric Villemain <cedric.villemain.debian@gmail.com> writes: > why do we care if there is a dash in the middle of a text where there > are no numbers ? Umm ... we are not requiring version names to be numbers. regards, tom lane
2011/2/14 Tom Lane <tgl@sss.pgh.pa.us>: > Cédric Villemain <cedric.villemain.debian@gmail.com> writes: >> why do we care if there is a dash in the middle of a text where there >> are no numbers ? > > Umm ... we are not requiring version names to be numbers. good point .... I was believing we had something like multi-name-1.2.3-5.6.7 at a maximum. > > regards, tom lane > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
tgl@sss.pgh.pa.us (Tom Lane) writes: > Peter Eisentraut <peter_e@gmx.net> writes: >> On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote: >>> Peter Eisentraut <peter_e@gmx.net> writes: >>>> Why do the extension load files need two dashes, like xml2--1.0.sql? >>>> Why isn't one enough? > >>> Because we'd have to forbid dashes in extension name and version >>> strings. This was judged to be a less annoying solution. See >>> yesterday's discussion. > >> I'm not convinced. There was nothing in that discussion why any >> particular character would have to be allowed in a version number. > > Well, there's already a counterexample in the current contrib stuff: > uuid-ossp. We could rename that to uuid_ossp of course, but it's > not clear to me that there's consensus for forbidding dashes here. I suspect that "_" might be troublesome. Let me observe on Debian policy... It requires that package names consist as follows: Package names (both source and binary, see Package, Section 5.6.7) must consist only of lower case letters (a-z), digits(0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start withan alphanumeric character. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source I suspect that we'll need to have a policy analagous to that. Also worth observing: Debian package files are of the form: "${package}_${version}-${dversion}_${arch}.deb" where package and version have fairly obvious interpretation, and... - dversion indicates a sequence handled by Debian -arch indicates CPU architecture (i386, amd64, ...) Probably the dversion/arch bits aren't of interest to us, but the remainder of the notation used by Debian seems not inapplicable for us. -- let name="cbbrowne" and tld="gmail.com" in String.concat "@" [name;tld];; http://linuxdatabases.info/info/languages.html Signs of a Klingon Programmer - 4. "You cannot really appreciate Dilbert unless you've read it in the original Klingon."
On Mon, Feb 14, 2011 at 10:13 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: >> Why do the extension load files need two dashes, like xml2--1.0.sql? >> Why isn't one enough? > > Because we'd have to forbid dashes in extension name and version > strings. This was judged to be a less annoying solution. See > yesterday's discussion. Are we deparsing the names of the SQL files to infer the set of version numbers we have to worry about? It seems to me that if there's a list of known version numbers somewhere, we can use dash as the separator without any special restricton. For example foo-bar-baz-bletch.sql is either an upgrade script from version bar-baz to version bletch, or else it's an upgrade script from bar to baz-bletch. But presumably no real-world cases will actually be ambiguous, assuming any sort of half-way sane version numbering scheme. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > Are we deparsing the names of the SQL files to infer the set of > version numbers we have to worry about? It seems to me that if > there's a list of known version numbers somewhere, we can use dash as > the separator without any special restricton. The list of known version numbers is inferred from the available files, not vice versa. IMO that's a feature not a bug. A manually maintained list would just be one more thing to forget to update. regards, tom lane
On Feb 14, 2011, at 5:03 PM, Tom Lane wrote: >> Are we deparsing the names of the SQL files to infer the set of >> version numbers we have to worry about? It seems to me that if >> there's a list of known version numbers somewhere, we can use dash as >> the separator without any special restricton. > > The list of known version numbers is inferred from the available files, > not vice versa. IMO that's a feature not a bug. A manually maintained > list would just be one more thing to forget to update. Yes, but the truth is that the extension name, at least, is known from the control file. Best, David
"David E. Wheeler" <david@kineticode.com> writes: > On Feb 14, 2011, at 5:03 PM, Tom Lane wrote: >>> Are we deparsing the names of the SQL files to infer the set of >>> version numbers we have to worry about? It seems to me that if >>> there's a list of known version numbers somewhere, we can use dash as >>> the separator without any special restricton. >> The list of known version numbers is inferred from the available files, >> not vice versa. IMO that's a feature not a bug. A manually maintained >> list would just be one more thing to forget to update. > Yes, but the truth is that the extension name, at least, is known from the control file. Yeah, I think it's true in the current code base that we always know the extension name we are interested in. However, that's no protection if we allow extensions to contain the separator substring. Considerfoo--bar--baz.sql Is this an update script for foo (from version bar to version baz), or is it an install script for some other extension named foo--bar? Also, I think it'd be better if we didn't assume that we will always know the extension name when trying to make sense of a script name. That's the sort of assumption that will bite you on the rear eventually. regards, tom lane
On Feb 14, 2011, at 8:18 PM, Tom Lane wrote: >> >> Yes, but the truth is that the extension name, at least, is known from the control file. > > Yeah, I think it's true in the current code base that we always know the > extension name we are interested in. However, that's no protection if > we allow extensions to contain the separator substring. Consider > foo--bar--baz.sql > Is this an update script for foo (from version bar to version baz), > or is it an install script for some other extension named foo--bar? > > Also, I think it'd be better if we didn't assume that we will always > know the extension name when trying to make sense of a script name. > That's the sort of assumption that will bite you on the rear eventually. Works for me. Best, David
On Mon, Feb 14, 2011 at 8:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Are we deparsing the names of the SQL files to infer the set of >> version numbers we have to worry about? It seems to me that if >> there's a list of known version numbers somewhere, we can use dash as >> the separator without any special restricton. > > The list of known version numbers is inferred from the available files, > not vice versa. IMO that's a feature not a bug. A manually maintained > list would just be one more thing to forget to update. I could go either way on that one; I was just throwing it up against the wall to see whether it would stick. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On mån, 2011-02-14 at 15:08 -0500, Tom Lane wrote: > Umm ... we are not requiring version names to be numbers. That's certainly interesting. Why?
On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote: > I guess the real question is what's Peter's concrete objection to the > double-dash method? It just looks a bit silly and error prone. And other packaging systems have been doing without it for decades.
Peter Eisentraut <peter_e@gmx.net> writes: > On mån, 2011-02-14 at 15:08 -0500, Tom Lane wrote: >> Umm ... we are not requiring version names to be numbers. > That's certainly interesting. Why? There isn't any packaging system anywhere on the planet that requires them to be purely numeric. By the time you get done allowing for multiple dots and "alpha" or "beta" and other such stuff, you might as well try to be agnostic about what they contain. regards, tom lane
On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote: >> I guess the real question is what's Peter's concrete objection to the >> double-dash method? > > It just looks a bit silly and error prone. And other packaging systems > have been doing without it for decades. how about : we use a single dash as the separator, and if the extension author insists on having a dash in the name, as a punishment he must duplicate the dash, i.e.: uuid--ossp-1.0--5.5.sql Greetings Marcin Mańk
Peter Eisentraut <peter_e@gmx.net> writes: > On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote: >> I guess the real question is what's Peter's concrete objection to the >> double-dash method? > It just looks a bit silly and error prone. And other packaging systems > have been doing without it for decades. I can't claim close familiarity with Debian's conventions in this matter, but I do know about RPM's, and I'm uneager to duplicate that silliness. Magic conversion of dots to underscores (sometimes), complete inability to determine which part of the package filename is which without external knowledge, etc. Aside from the double-dash method, we kicked around using colons and pluses as separators (and then forbidding just those characters in extension and version names). Any of those would be workable, but it's not clear to me that any of them have any particular cosmetic advantage over any others. In any case, the time to be voting on them is past so far as I'm concerned. The work is already done and I'm uneager to do it over on one person's say-so. regards, tom lane
On Feb 15, 2011, at 12:32 PM, Tom Lane wrote: > Aside from the double-dash method, we kicked around using colons and > pluses as separators (and then forbidding just those characters in > extension and version names). Any of those would be workable, but it's > not clear to me that any of them have any particular cosmetic advantage > over any others. In any case, the time to be voting on them is past so > far as I'm concerned. The work is already done and I'm uneager to do it > over on one person's say-so. I'd prefer a single character, but can live with -- just fine. Best, David
On Tue, Feb 15, 2011 at 3:26 PM, marcin mank <marcin.mank@gmail.com> wrote: > On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >> On mån, 2011-02-14 at 12:14 -0500, Tom Lane wrote: >>> I guess the real question is what's Peter's concrete objection to the >>> double-dash method? >> >> It just looks a bit silly and error prone. And other packaging systems >> have been doing without it for decades. > > how about : we use a single dash as the separator, and if the > extension author insists on having a dash in the name, as a punishment > he must duplicate the dash, i.e.: > uuid--ossp-1.0--5.5.sql That has a certain poetic justice to it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Feb 15, 2011 at 14:12, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Feb 15, 2011 at 3:26 PM, marcin mank <marcin.mank@gmail.com> wrote: >> how about : we use a single dash as the separator, and if the >> extension author insists on having a dash in the name, as a punishment >> he must duplicate the dash, i.e.: >> uuid--ossp-1.0--5.5.sql > > That has a certain poetic justice to it. Im not sure I see the poetic justice in trying to punish others for *our* arbitrary naming rules. *shrug*
2011/2/16 Alex Hunsaker <badalex@gmail.com>: > On Tue, Feb 15, 2011 at 14:12, Robert Haas <robertmhaas@gmail.com> wrote: >> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank <marcin.mank@gmail.com> wrote: >>> how about : we use a single dash as the separator, and if the >>> extension author insists on having a dash in the name, as a punishment >>> he must duplicate the dash, i.e.: >>> uuid--ossp-1.0--5.5.sql >> >> That has a certain poetic justice to it. > > Im not sure I see the poetic justice in trying to punish others for > *our* arbitrary naming rules. *shrug* > We are going to push arbitrary rules anyway. I now believe (after chating wiht Dim) that the current rules are the less intrusive and the simplest at the time. Obviously it is new rules, but after all the -- help a good visibility for the human eye too. my-2coolextension--1.2alpha--go2beta.sql .... -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On tis, 2011-02-15 at 15:32 -0500, Tom Lane wrote: > I can't claim close familiarity with Debian's conventions in this > matter, but I do know about RPM's, and I'm uneager to duplicate that > silliness. Magic conversion of dots to underscores (sometimes), > complete inability to determine which part of the package filename is > which without external knowledge, etc. FYI, the system in Debian is that '_' separate package name and version, and '_' is not allowed in package name or version. I guess since we want to allow both '_' and '-' in package names, we can't really do that or anything similar.