Re: Finer Extension dependencies

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Finer Extension dependencies
Date: 2012-04-05 16:19:15
Message-ID: CA+Tgmoa01EjSVB60dfjsnz0EacWR9pytzmS+eKGT=dRUbjp+Xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 3, 2012 at 4:15 AM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>>> On Apr 2, 2012, at 11:24 AM, Peter Eisentraut wrote:
>>>> Or an extension could specify itself which version numbering scheme it
>>>> uses.  This just has to be a reference to a type, which in turn could be
>>>> semver, debversion, or even just numeric or text (well, maybe name).
>>>> Then you'd just need to use the comparison operators of that type to
>>>> figure things out.
>
> That's exactly what I'm trying to avoid :)
>
>> Well, the primary argument for avoiding version comparison semantics to
>> begin with was exactly that we didn't want to mandate a particular
>> version-numbering scheme.  However, if we're going to decide that we
>> have to have version comparisons, I think we should just bite the bullet
>> and specify one version numbering scheme.  More than one is going to add
>> complexity, sow confusion, and not really buy anything.
>
> I still believe we don't *need* any numbering scheme for extension
> versions. Now, maybe we as a community want one. I'm voting against.

Examining this thread, I think there is insufficient consensus to push
this patch into 9.2. It's not entirely clear that this patch isn't
what we want, but it's not entirely clear that it is what we want
either, and I think it's too late in the release cycle to push
anything into the release that we're not fairly sure we actually want,
because there won't be time to revisit that decision before this ends
up out in the wild. It's also not the sort of thing we can just whack
around in the next release if we get it wrong, because APIs for coping
with versioning are exactly the kind of thing that you can't go change
at the drop of a hat. I'm therefore marking this Returned with
Feedback.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2012-04-05 16:24:55 Re: pg_upgrade improvements
Previous Message Tom Lane 2012-04-05 16:12:48 Re: pg_upgrade improvements