Robert Haas writes:
> 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
>
On Tue, Apr 3, 2012 at 4:15 AM, Dimitri Fontaine wrote:
> Tom Lane 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
Tom Lane 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).
On Apr 2, 2012, at 11:58 AM, Tom Lane wrote:
>> Sounds like a lot of work for core to maintain various version comparison
>> schemes
>
> Well, the primary argument for avoiding version comparison semantics to
> begin with was exactly that we didn't want to mandate a particular
> version-numberin
"David E. Wheeler" 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 n
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
On tor, 2012-03-29 at 14:48 -0400, Robert Haas wrote:
> Frankly, I'm not sure we bet on the right horse in not mandating a
> version numbering scheme from the beginning. But given that we
> didn't, we probably don't want to get too forceful about it too
> quickly. However, we could ease into it b
Tom Lane writes:
>> That's how I did it first, but Alvaro opposed to that because it allows
>> for more than one extension to provide for the same feature name.
>> http://archives.postgresql.org/pgsql-hackers/2012-03/msg01425.php
>
> Right, but the question that has to be considered is how often
Dimitri Fontaine writes:
> Tom Lane writes:
>> Peter Eisentraut writes:
>>> At the very least, I would suggest that feature names are per-extension.
>> Yeah, I had about come to that conclusion too. A global namespace for
>> them would be a mistake given lack of central coordination.
> That's
Tom Lane writes:
> Peter Eisentraut writes:
>> At the very least, I would suggest that feature names are per-extension.
>
> Yeah, I had about come to that conclusion too. A global namespace for
> them would be a mistake given lack of central coordination.
That's how I did it first, but Alvaro o
On Mar 29, 2012, at 11:48 AM, Robert Haas wrote:
> Frankly, I'm not sure we bet on the right horse in not mandating a
> version numbering scheme from the beginning. But given that we
> didn't, we probably don't want to get too forceful about it too
> quickly. However, we could ease into it by do
On tor, 2012-03-29 at 14:39 -0400, Robert Haas wrote:
> > but it breaks down when you, say, want to
> > wrap your egg into a Debian package.
>
> *blink* Huh?
Well, you can't represent that mechanism in a Debian (or RPM) package
dependency. So the alternatives are make it a Recommends and add a
f
On Thu, Mar 29, 2012 at 2:25 PM, Tom Lane wrote:
> Yeah. AFAIK, nobody actually does that. In my experience with Red Hat
> packages, so-called "virtual Provides" (which are exactly equivalent to
> this proposed feature) are used only for cases where there is or is
> planned to be more than one p
Peter Eisentraut writes:
> At the very least, I would suggest that feature names are per-extension.
Yeah, I had about come to that conclusion too. A global namespace for
them would be a mistake given lack of central coordination.
regards, tom lane
--
Sent via pgsql-hac
On Thu, Mar 29, 2012 at 2:28 PM, Peter Eisentraut wrote:
> On ons, 2012-03-28 at 23:00 -0700, Hitoshi Harada wrote:
>> I totally agree with Robert's point that one feature is not
>> standardized and nobody can tell how you can depend on the feature in
>> the end. Mind you, I've never heard about
On tor, 2012-03-29 at 09:51 +0200, Dimitri Fontaine wrote:
> I don't want to introduce version dependency, because I don't think we
> need it. If you want to compare what we're doing here with say debian
> packaging, then look at how they package libraries. The major version
> number is now part of
On ons, 2012-03-28 at 23:00 -0700, Hitoshi Harada wrote:
> I totally agree with Robert's point that one feature is not
> standardized and nobody can tell how you can depend on the feature in
> the end. Mind you, I've never heard about building dependency by its
> name as a string in other packagin
Robert Haas writes:
> So the idea is that you're actually supposed to separately catalog
> each feature you added (e.g. each new function), so that people can
> depend specifically on those features.
> I don't really have the foggiest idea how people using other packaging
> systems handle this.
Robert Haas writes:
>>> provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5,
>>> foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-2.3,
>>> foobar-3.0, foobar-3.1
>>
>> This is what I have expected to do. In new releases of pgTAP, I’d probably
>> just add version lines. I mi
On Thu, Mar 29, 2012 at 1:48 PM, David E. Wheeler wrote:
> On Mar 29, 2012, at 4:42 AM, Robert Haas wrote:
>
>> 2. Add a new feature to the provides line with every release that does
>> anything other than fix bugs, leading to:
>>
>> provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, fooba
On Mar 29, 2012, at 4:42 AM, Robert Haas wrote:
> 2. Add a new feature to the provides line with every release that does
> anything other than fix bugs, leading to:
>
> provides = foobar-1.1, foobar-1.2, foobar-1.3, foobar-1.4, foobar-1.5,
> foobar-1.6, foobar-2.0, foobar-2.1, foobar-2.2, foobar-
On Thu, Mar 29, 2012 at 8:01 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I think that technically this patch can be polished well enough to
>> commit in the time we have available, but the question of whether
>> it's the right design is harder, and I don't want that to be my
>> call alone
"Kevin Grittner" writes:
> I gather from previous posts that the intent isn't to allow different
> packages from different authors to provide a common and compatible
> feature; but what happens in the current design if someone
> accidentally or maliciously produces an extension which provides the
On Thu, Mar 29, 2012 at 1:01 PM, Kevin Grittner
wrote:
> I gather from previous posts that the intent isn't to allow different
> packages from different authors to provide a common and compatible
> feature; but what happens in the current design if someone
> accidentally or maliciously produces an
Robert Haas wrote:
> I think that technically this patch can be polished well enough to
> commit in the time we have available, but the question of whether
> it's the right design is harder, and I don't want that to be my
> call alone.
I gather from previous posts that the intent isn't to allo
On Thu, Mar 29, 2012 at 4:37 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> So my question is why you cannot depend on ip4r in that case. If some
>> version of the module introduces ipv6, then let's depend on that
>> version. It doesn't explain why a string feature name is needed.
>
>
Hi,
Thanks for your review!
Robert Haas writes:
> I think the lack of pg_upgrade support is a must-fix before commit.
I though that would only be a TODO for 9.2 to 9.3 upgrades. When
upgrading from 9.1 to 9.2, pg_upgrade will directly stuff extensions
using InsertExtensionTuple() with an empty
Hitoshi Harada writes:
> So my question is why you cannot depend on ip4r in that case. If some
> version of the module introduces ipv6, then let's depend on that
> version. It doesn't explain why a string feature name is needed.
The only operator we have to compare version strings in PostgreSQL
On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> Frankly I'm still against this patch. Since I started to review it
>> I've never been convinced with the use case. Yeah, someone said it'd
>> be useful to him, but as a developer of some of PGXN modules I don'
Hitoshi Harada writes:
> Frankly I'm still against this patch. Since I started to review it
> I've never been convinced with the use case. Yeah, someone said it'd
> be useful to him, but as a developer of some of PGXN modules I don't
> see it. I totally agree with Robert's point that one featur
On Wed, Mar 28, 2012 at 8:52 AM, Robert Haas wrote:
> On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
> wrote:
>>> In practice, however, that sounds like a real pain in the neck. I
>>> would expect most people who were packaging extensions to handle a
>>> situation like this by forcing the us
On Wed, Mar 28, 2012 at 3:09 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Could you possibly generate a new diff to save me the trouble of
>> fixing the one you sent before?
>
> Please find it attached, it looks better now, and I rebased it against
> master for good measure (no conflicts)
On Wed, Mar 28, 2012 at 12:11 PM, Dimitri Fontaine
wrote:
>> On a more prosaic note, you seem to have made a mistake when
>> generating the v5 diff. It includes reverts of a couple of unrelated,
>> recent patches.
>
> Ouch. It seems to happen to me too often. I probably need to get the
> shallow
Robert Haas writes:
> accomplish. Instead, you're just concerned about allowing some but
> not all versions of package A to provide feature F, so that other
> extensions can depend on F to get the specific version of A that they
> need (and not, as I had assumed, so that they can get either A or
On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
wrote:
>> In practice, however, that sounds like a real pain in the neck. I
>> would expect most people who were packaging extensions to handle a
>> situation like this by forcing the user to provide the name of the
>> function to be called, eith
Robert Haas writes:
> I'm not completely convinced that the case has been made that this is
> a useful thing to have.
You're basically saying that the current lack of extension distribution
is a good reason for not building the tools allowing to create said
distribution. WTF?
(PGXN uses the wo
On Thu, Mar 22, 2012 at 2:08 PM, Dimitri Fontaine
wrote:
> Alvaro Herrera writes:
>> get_available_versions_for_extension seems to contain a bunch of
>> commented-out lines ...
>
> Damn. Sorry about that. Here's a cleaned-up version of the patch.
I'm not completely convinced that the case has b
Alvaro Herrera writes:
> So you still need an index on (oid), one on (extoid), and one on
> (extfeature).
Yes. And the main use case for the index on (extoid) is listing a given
extension's features, that we want to order by their name, then the set
of indexes I've been defining is now:
Indexes:
Excerpts from Dimitri Fontaine's message of vie mar 23 16:51:57 -0300 2012:
>
> Alvaro Herrera writes:
> >> Yes, for pg_depend, no I don't know how to make that work with pointing
> >> to the extensions directly, because the whole point here is to be able
> >> to depend on a feature rather than
Alvaro Herrera writes:
>> Yes, for pg_depend, no I don't know how to make that work with pointing
>> to the extensions directly, because the whole point here is to be able
>> to depend on a feature rather than the whole extension.
>
> Yes, I understand that -- but would it work to have the feature
Excerpts from Dimitri Fontaine's message of vie mar 23 13:12:22 -0300 2012:
>
> Alvaro Herrera writes:
> > Why do features have OIDs? Is this for pg_depend entries? If so, would
> > it work to have pg_depend entries point to extensions instead?
>
> Yes, for pg_depend, no I don't know how to m
Alvaro Herrera writes:
> Why do features have OIDs? Is this for pg_depend entries? If so, would
> it work to have pg_depend entries point to extensions instead?
Yes, for pg_depend, no I don't know how to make that work with pointing
to the extensions directly, because the whole point here is to
Excerpts from Dimitri Fontaine's message of vie mar 23 12:26:47 -0300 2012:
>
> Alvaro Herrera writes:
> > Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:
> >
> >> =# \d pg_extension_feature
> >> Table "pg_catalog.pg_extension_feature"
> >> Column | Type |
Alvaro Herrera writes:
> Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:
>
>> =# \d pg_extension_feature
>> Table "pg_catalog.pg_extension_feature"
>> Column | Type | Modifiers
>> +--+---
>>extoid | oid | not null
>>extf
Excerpts from Dimitri Fontaine's message of vie mar 23 11:05:37 -0300 2012:
> =# \d pg_extension_feature
> Table "pg_catalog.pg_extension_feature"
> Column | Type | Modifiers
> +--+---
>extoid | oid | not null
>extfeature | name | not null
> In
Alvaro Herrera writes:
> Hmm .. feature names should be globally unique, right? If so I think
> you're missing an UNIQUE index on the new catalog, covering just the
> feature name. You have a two column index (extoid, featurename), so you
> could have two different extensions providing the same
Excerpts from Dimitri Fontaine's message of jue mar 22 15:08:27 -0300 2012:
> Alvaro Herrera writes:
> > get_available_versions_for_extension seems to contain a bunch of
> > commented-out lines ...
>
> Damn. Sorry about that. Here's a cleaned-up version of the patch.
Hmm .. feature names shoul
Alvaro Herrera writes:
> get_available_versions_for_extension seems to contain a bunch of
> commented-out lines ...
Damn. Sorry about that. Here's a cleaned-up version of the patch.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a
Excerpts from Dimitri Fontaine's message of jue mar 22 14:38:29 -0300 2012:
> Hi,
>
> Again, thanks very much for the review. Here's an updated patch (just
> merged against master) fixing most of your comments here. I couldn't
> reproduce previous problems with the attached:
get_available_vers
Hi,
Again, thanks very much for the review. Here's an updated patch (just
merged against master) fixing most of your comments here. I couldn't
reproduce previous problems with the attached:
- DROP EXTENSION was broken, asking to cascade to self
- CREATE EXTENSION was bypassing "requires"
I c
On Wed, Mar 21, 2012 at 11:11 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I don't think we can wait any longer for this; we're now more than two
>> months in to this CommitFest, and command triggers is still in full
>> swing.
>
> Is it possible to have another day to send out a revised p
Robert Haas writes:
> I don't think we can wait any longer for this; we're now more than two
> months in to this CommitFest, and command triggers is still in full
> swing.
Is it possible to have another day to send out a revised patch? The
problem reported is either a show stopper or a less-than
On Thu, Mar 8, 2012 at 9:39 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> Dimitri, are you going to post an updated patch for this CF?
>
> Yes, I intend to do that. Not sure about diverting from the command
> trigger patch while Thom is full speed on reviewing and helping me write
> the f
Robert Haas writes:
> Dimitri, are you going to post an updated patch for this CF?
Yes, I intend to do that. Not sure about diverting from the command
trigger patch while Thom is full speed on reviewing and helping me write
the full covering test cases, though.
Regards,
--
Dimitri Fontaine
http
On Tue, Feb 28, 2012 at 5:34 AM, Hitoshi Harada wrote:
> Quickly reviewed the patch and found some issues.
>
> - There are some mixture of pg_extension_feature and pg_extension_feature"s"
> - The doc says pg_extension_feature"s" has four columns but it's not true.
> - Line 608 is bad. In the loop,
On Fri, Feb 24, 2012 at 2:09 PM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
>> I confirmed DROP EXTENSION is fixed now. In turn, it seems to me
>> "requires" doesn't work. My test ext2.control looks like:
>
> I'm very sorry about that. It's all about playing with pg_depend and
> I've fail
Hitoshi Harada writes:
> I confirmed DROP EXTENSION is fixed now. In turn, it seems to me
> "requires" doesn't work. My test ext2.control looks like:
I'm very sorry about that. It's all about playing with pg_depend and
I've failed to spend enough time on that very topic to send a patch that
jus
On Mon, Feb 13, 2012 at 3:18 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Sorry for the delays, I'm back on PostgreSQL related work again.
>
> Hitoshi Harada writes:
I just tried DROP EXTENSION now, and found it broken :(
>
> Please find v2 of the patch. I did change the dependency management in
>
Hi,
Sorry for the delays, I'm back on PostgreSQL related work again.
Hitoshi Harada writes:
>>> I just tried DROP EXTENSION now, and found it broken :(
Please find v2 of the patch. I did change the dependency management in
between the simple cases and the more challenging ones and forgot that
Hitoshi Harada writes:
> Ping. In case you don't have updates soon, I'll mark Returned with Feedback.
Pong. Sorry about my recent silence.
I've not been in a position to work on this recently, and am done with
those other duties now. I intend to be posting an updated patch soon
now. Please wa
On Mon, Jan 23, 2012 at 3:06 AM, Hitoshi Harada wrote:
> On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
> wrote:
>> Hitoshi Harada writes:
> - What happens if DROP EXTENSION ... CASCADE? Does it work?
It should, what happens when you try? :)
>>>
>>> I just tried DROP EXTENSION n
On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
wrote:
> Hitoshi Harada writes:
- What happens if DROP EXTENSION ... CASCADE? Does it work?
>>>
>>> It should, what happens when you try? :)
>>
>> I just tried DROP EXTENSION now, and found it broken :(
>>
>> db1=# create extension kmeans;
>>
Hitoshi Harada writes:
>>> "pg_extension_feature_index" UNIQUE, btree (extoid, extfeature)
> Do you mean you want UNIQUE constraint by this index? I found the
> usage is to search feature by (only) its name, so I wondered if extoid
> is not necessary.
I guess you're right and that's something
On Sat, Jan 21, 2012 at 9:20 AM, Dimitri Fontaine
wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada writes:
>> The patch applies with one reject, which I could fix easily. The make
>> check passed.
>
> Bitrot happens fast in this season… will produce another version of the
On 21 Leden 2012, 18:20, Dimitri Fontaine wrote:
> Hi,
>
> Thank you for reviewing this patch!
>
> Hitoshi Harada writes:
>>
>> Next, some questions:
>> - Why is the finer dependency needed? Do you have tangible example
>> that struggles with the dependency granularity? I feel so good about
>> the
Hi,
Thank you for reviewing this patch!
Hitoshi Harada writes:
> The patch applies with one reject, which I could fix easily. The make
> check passed.
Bitrot happens fast in this season… will produce another version of the
patch.
> Table "pg_catalog.pg_extension_feature"
>Column | Type
On Sun, Dec 18, 2011 at 6:36 AM, Dimitri Fontaine
wrote:
> Hi,
>
> The extensions work we began in 9.1 is not yet finished entirely
> (*cough*), so I'm opening a new patch series here by attacking the
> dependency problems.
>
> Some people want us to manage extension version numbers with sorting
>
67 matches
Mail list logo
