why two dashes in extension load files
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
=?ISO-8859-1?Q?C=E9dric_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>:
=?ISO-8859-1?Q?C=E9dric_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 with an 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. 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.
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?
