On Tue, Apr 3, 2012 at 4:15 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.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
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.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
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 by
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
David E. Wheeler da...@justatheory.com 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
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-numbering
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 28, 2012 at 8:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
Hitoshi Harada umi.tan...@gmail.com 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
On Thu, Mar 29, 2012 at 12:51 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com 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
Hitoshi Harada umi.tan...@gmail.com 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
Hi,
Thanks for your review!
Robert Haas robertmh...@gmail.com 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
On Thu, Mar 29, 2012 at 4:37 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com 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
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 allow
On Thu, Mar 29, 2012 at 1:01 PM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Thu, Mar 29, 2012 at 8:01 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
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-2.3,
On Thu, Mar 29, 2012 at 1:48 PM, David E. Wheeler da...@justatheory.com 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,
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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 packaging
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 Thu, Mar 29, 2012 at 2:28 PM, Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
--
On Thu, Mar 29, 2012 at 2:25 PM, Tom Lane t...@sss.pgh.pa.us 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
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
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
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net 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
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net 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
On Thu, Mar 22, 2012 at 2:08 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com 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?
On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
Robert Haas robertmh...@gmail.com 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
On Wed, Mar 28, 2012 at 12:11 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
On Wed, Mar 28, 2012 at 3:09 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
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
Indexes:
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Dimitri Fontaine's message of vie mar 23 12:26:47 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Dimitri Fontaine's message of vie mar 23 13:12:22 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Dimitri Fontaine's message of vie mar 23 16:51:57 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
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
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:
Alvaro Herrera alvhe...@commandprompt.com 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
Excerpts from Dimitri Fontaine's message of jue mar 22 15:08:27 -0300 2012:
Alvaro Herrera alvhe...@commandprompt.com 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 ..
Alvaro Herrera alvhe...@commandprompt.com 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
On Thu, Mar 8, 2012 at 9:39 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Wed, Mar 21, 2012 at 11:11 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Feb 28, 2012 at 5:34 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
Quickly reviewed the patch and found some issues.
- There are some mixture of pg_extension_feature and pg_extension_features
- The doc says pg_extension_features has four columns but it's not true.
- Line 608 is bad.
Robert Haas robertmh...@gmail.com 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,
--
On Fri, Feb 24, 2012 at 2:09 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com 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
Hitoshi Harada umi.tan...@gmail.com 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
On Mon, Feb 13, 2012 at 3:18 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hi,
Sorry for the delays, I'm back on PostgreSQL related work again.
Hitoshi Harada umi.tan...@gmail.com writes:
I just tried DROP EXTENSION now, and found it broken :(
Please find v2 of the patch. I did
Hi,
Sorry for the delays, I'm back on PostgreSQL related work again.
Hitoshi Harada umi.tan...@gmail.com 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
On Mon, Jan 23, 2012 at 3:06 AM, Hitoshi Harada umi.tan...@gmail.com wrote:
On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com writes:
- What happens if DROP EXTENSION ... CASCADE? Does it work?
It should, what happens when you
Hitoshi Harada umi.tan...@gmail.com 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
On Sat, Jan 21, 2012 at 9:20 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hi,
Thank you for reviewing this patch!
Hitoshi Harada umi.tan...@gmail.com writes:
The patch applies with one reject, which I could fix easily. The make
check passed.
Bitrot happens fast in this season… will
Hitoshi Harada umi.tan...@gmail.com 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
On Mon, Jan 23, 2012 at 2:00 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hitoshi Harada umi.tan...@gmail.com 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=#
Hi,
Thank you for reviewing this patch!
Hitoshi Harada umi.tan...@gmail.com 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
On 21 Leden 2012, 18:20, Dimitri Fontaine wrote:
Hi,
Thank you for reviewing this patch!
Hitoshi Harada umi.tan...@gmail.com 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
On Sun, Dec 18, 2011 at 6:36 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr 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
67 matches
Mail list logo
