On May 17, 2011, at 9:44 AM, Peter van Hardenberg wrote:
> My apologies for wading in out of the blue here as a first time poster with
> big demands, but allow me to briefly state my hopes without trying to be too
> proscriptive about particular mechanisms.
You are not alone, I assure you. :-)
My apologies for wading in out of the blue here as a first time poster with
big demands, but allow me to briefly state my hopes without trying to be too
proscriptive about particular mechanisms.
My hope here is that the extension model should eventually enable me to
offer the ability for non-super
On Thu, May 12, 2011 at 3:29 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Okay, how we add a "revision" key to the control file and extrevision to
>>> the pg_extension catalog. Its type can be "TEXT" and is optional for use
>>> by extensions.
>>
>> How would pg_extension.extrevision be k
Robert Haas writes:
>> Okay, how we add a "revision" key to the control file and extrevision to
>> the pg_extension catalog. Its type can be "TEXT" and is optional for use
>> by extensions.
>
> How would pg_extension.extrevision be kept up to date? AFAICS, the
> whole point is that you might swap
On Wed, May 11, 2011 at 10:48 PM, David E. Wheeler wrote:
> On May 11, 2011, at 2:47 PM, Robert Haas wrote:
>
>>> Okay, how we add a "revision" key to the control file and extrevision to
>>> the pg_extension catalog. Its type can be "TEXT" and is optional for use by
>>> extensions.
>>>
>>> This
On May 11, 2011, at 2:47 PM, Robert Haas wrote:
>> Okay, how we add a "revision" key to the control file and extrevision to the
>> pg_extension catalog. Its type can be "TEXT" and is optional for use by
>> extensions.
>>
>> This would allow extension authors to identify the base version of an
On Wed, May 11, 2011 at 5:06 PM, David E. Wheeler wrote:
> On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote:
>
>> So maybe it's half-assed. Maybe the version can be anything but the revision
>> must be an integer. Maybe there's a `pg_extension_version($extension_name)`
>> function that return
On Apr 28, 2011, at 2:16 PM, David E. Wheeler wrote:
> So maybe it's half-assed. Maybe the version can be anything but the revision
> must be an integer. Maybe there's a `pg_extension_version($extension_name)`
> function that returns ARRAY[$version, $revision], and the revision is set in
> the
Hey folks,
I'd kind of like to get this issue nailed down soon so I can update the PGXN
HOWTO and illustrate a generally agreed-upon best practice for extension
developers. How *do* we want people to use versions in their extension?
Thanks,
David
On Apr 28, 2011, at 2:16 PM, David E. Wheeler
On Apr 28, 2011, at 7:04 AM, Tom Lane wrote:
> I think what we're discussing here is bug-fix revisions that don't
> affect the SQL declarations for the extension. Presumably, that means a
> change in the C code, so the shared library is the right place to keep
> the revision number. A version nu
On Thu, Apr 28, 2011 at 3:04 PM, Tom Lane wrote:
> Daniele Varrazzo writes:
>> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>>> How about each .so containing a version callback?
>>>
>>> Thus you can show what is the version of underlying implementation
>>> without needing to mess with cat
Daniele Varrazzo writes:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>> How about each .so containing a version callback?
>>
>> Thus you can show what is the version of underlying implementation
>> without needing to mess with catalogs just to keep track of patchlevel
>> of C code.
>
On Thu, Apr 28, 2011 at 4:40 PM, Daniele Varrazzo
wrote:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
>> On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
>> wrote:
>>> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
>>> wrote:
Tom Lane writes:
> If you didn't change the in
On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen wrote:
> On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
> wrote:
>> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
>> wrote:
>>> Tom Lane writes:
If you didn't change the install script then it's not necessary to
execute ALTER EXTENSI
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
wrote:
> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
> wrote:
>> Tom Lane writes:
>>> If you didn't change the install script then it's not necessary to
>>> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
>>> pg_exten
On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
wrote:
> Tom Lane writes:
>> If you didn't change the install script then it's not necessary to
>> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
>> pg_extensions catalog has to reflect the bug fix level of an extension,
>>
Tom Lane writes:
> If you didn't change the install script then it's not necessary to
> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the
> pg_extensions catalog has to reflect the bug fix level of an extension,
> but that is *not* the intention. If it did reflect that, you'd
On Mon, Apr 25, 2011 at 12:17 PM, David E. Wheeler wrote:
> On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:
>
>> Really, that means you just a sql function to your extension,
>> somethign similary to uname -a, or rpm -qi, which includes something
>> that is *forced* to change the postgresql cata
On Apr 25, 2011, at 9:14 AM, Aidan Van Dyk wrote:
> Really, that means you just a sql function to your extension,
> somethign similary to uname -a, or rpm -qi, which includes something
> that is *forced* to change the postgresql catalog view of your
> extension every time you ship a new version (m
On Mon, Apr 25, 2011 at 12:00 PM, David E. Wheeler wrote:
> These are really great points. I knew I wasn't thrilled about this suggest,
> but wasn't sure why. Frankly, I think it will be really confusing to users
> who think they have FooBar 1.2.2 installed but see only 1.2 in the database.
>
On Apr 25, 2011, at 5:49 AM, Robert Haas wrote:
> I think it's a bit awkward that we have to do it this way, though.
> The installed version of the extension at the SQL level won't match
> what the user thinks they've installed. Granted, it'll be in the
> ballpark (1.0 vs 1.0.3, for example) but
On Sun, Apr 24, 2011 at 6:03 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
>>> Hmm ... it's sufficient, but I think people are going to be confused as
>>> to proper usage if you call two different things the "version". In RPM
>>> terminology the
On Apr 24, 2011, at 3:03 PM, Tom Lane wrote:
> Yeah. It seems like a bad idea if the distribution "name" doesn't
> include sufficient information to tell which version it contains.
> I had in mind a convention like "distribution version x.y.z always
> contains extension version x.y". Seems like
"David E. Wheeler" writes:
> On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
>> Hmm ... it's sufficient, but I think people are going to be confused as
>> to proper usage if you call two different things the "version". In RPM
>> terminology there's a clear difference between "version" and "release";
On Sun, Apr 24, 2011 at 10:46 PM, Tom Lane wrote:
> Daniele Varrazzo writes:
>> On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane wrote:
>>> If you did not actually change the contents of the install script, you
>>> should not change its version number either.
>
>> Sorry, I'm not entirely convinced. If
On Apr 24, 2011, at 2:55 PM, Tom Lane wrote:
> Hmm ... it's sufficient, but I think people are going to be confused as
> to proper usage if you call two different things the "version". In RPM
> terminology there's a clear difference between "version" and "release";
> maybe some similar wording sh
"David E. Wheeler" writes:
> On Apr 24, 2011, at 2:46 PM, Tom Lane wrote:
>> IMO it'd be better if the bug fix level was tracked outside the
>> database, for instance via an RPM package version/release number.
>> I'm not sure whether PGXN has anything for that at the moment.
> Distributions may h
On Apr 24, 2011, at 2:46 PM, Tom Lane wrote:
> IMO it'd be better if the bug fix level was tracked outside the
> database, for instance via an RPM package version/release number.
> I'm not sure whether PGXN has anything for that at the moment.
Distributions may have their own versions independent
Daniele Varrazzo writes:
> On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane wrote:
>> If you did not actually change the contents of the install script, you
>> should not change its version number either.
> Sorry, I'm not entirely convinced. If I release an extension 1.0, then
> find a bug in the C cod
On Apr 23, 2011, at 1:03 PM, Dimitri Fontaine wrote:
> Daniele Varrazzo writes:
>> For my extension I'm less concerned by having the install sql named in
>> different ways or by the upgrade sql as all these files are generated
>> by scripts. You may find useful this one
>
> You can also generate
On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> * Another, minor point: If I release a new version with no changes to the
>> code (as I've done today, just changing the make stuff and documentation),
>> it's kind of annoying that I'd need to have a migration sc
Daniele Varrazzo writes:
> For my extension I'm less concerned by having the install sql named in
> different ways or by the upgrade sql as all these files are generated
> by scripts. You may find useful this one
You can also generate that reliably in SQL. You install your extension
with CREATE
On Apr 20, 2011, at 8:25 PM, David E. Wheeler wrote:
> Okay. What about building something into PGXS that could handle these kinds
> of things? I just can't help but wonder if there isn't some better way to do
> the kinds of things that Daniele and I have resorted to to use a PostgreSQL
> versi
On Apr 20, 2011, at 8:04 PM, Daniele Varrazzo wrote:
> Specifically, I parse the version from the control file using:
>
>PGMP_VERSION=$(shell grep default_version pgmp.control | sed -e
> "s/default_version = '\(.*\)'/\1/")
Oh, that's not bad. Thanks.
> so the Makefile doesn't have to be mai
On Apr 20, 2011, at 8:16 PM, Tom Lane wrote:
> I'm not interested in kluging things up after the fact to try to somehow
> reverse that mindset and make pre-extension-world and post-extension-world
> scripts compatible. That looks like long-term pain in return for very
> small short-term gain to m
"David E. Wheeler" writes:
> * I would love to be able to maintain a single file for the default
> version of an extension.
Basically, this wasn't and isn't on the list of considerations. There
has never been any expectation that a contrib module could use the exact
same SQL script for every Pos
On Thu, Apr 21, 2011 at 1:14 AM, David E. Wheeler wrote:
> I finally got round to updating a couple of my extensions to support 9.1
> extensions. Unlike the contrib extensions, these needed to target older
> versions of PostgreSQL, as well. Case in point, the semver data type; you
> might find
Hackers,
I finally got round to updating a couple of my extensions to support 9.1
extensions. Unlike the contrib extensions, these needed to target older
versions of PostgreSQL, as well. Case in point, the semver data type; you might
find the Makefile of particular interest:
https://github.c
38 matches
Mail list logo
