Re: 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(at)gmx(dot)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(at)gmx(dot)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(at)gmx(dot)net> writes:
> On mn, 2011-02-14 at 10:13 -0500, Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmx(dot)net> wrote:
> On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote:
>> Peter Eisentraut <peter_e(at)gmx(dot)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(at)kineticode(dot)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(at)sss(dot)pgh(dot)pa(dot)us>:
> "David E. Wheeler" <david(at)kineticode(dot)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(dot)villemain(dot)debian(at)gmail(dot)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(at)sss(dot)pgh(dot)pa(dot)us>:
> =?ISO-8859-1?Q?C=E9dric_Villemain?= <cedric(dot)villemain(dot)debian(at)gmail(dot)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(at)postgresql(dot)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(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane) writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On mån, 2011-02-14 at 10:13 -0500, Tom Lane wrote:
>>> Peter Eisentraut <peter_e(at)gmx(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmail(dot)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(at)kineticode(dot)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(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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(at)gmx(dot)net> writes:
> On mn, 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(at)gmx(dot)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(at)gmx(dot)net> writes:
> On mn, 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(dot)mank(at)gmail(dot)com> wrote:
> On Tue, Feb 15, 2011 at 9:16 PM, Peter Eisentraut <peter_e(at)gmx(dot)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(at)gmail(dot)com> wrote:
> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank <marcin(dot)mank(at)gmail(dot)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(at)gmail(dot)com>:
> On Tue, Feb 15, 2011 at 14:12, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank <marcin(dot)mank(at)gmail(dot)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.