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
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. :-)
On Thu, May 12, 2011 at 3:29 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
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
On Wed, May 11, 2011 at 5:06 PM, David E. Wheeler da...@kineticode.com 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)`
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
extension
On Wed, May 11, 2011 at 10:48 PM, David E. Wheeler da...@kineticode.com 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
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
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us 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
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
If you didn't change the install script then it's not necessary to
execute ALTER EXTENSION
On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen mark...@gmail.com wrote:
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Tom Lane t...@sss.pgh.pa.us writes:
If you didn't change
On Thu, Apr 28, 2011 at 4:40 PM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen mark...@gmail.com wrote:
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo
daniele.varra...@gmail.com wrote:
On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine
Daniele Varrazzo daniele.varra...@gmail.com writes:
On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen mark...@gmail.com 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
On Thu, Apr 28, 2011 at 3:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniele Varrazzo daniele.varra...@gmail.com writes:
On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen mark...@gmail.com wrote:
How about each .so containing a version callback?
Thus you can show what is the version of underlying
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
On Sun, Apr 24, 2011 at 6:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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.
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 Mon, Apr 25, 2011 at 12:00 PM, David E. Wheeler da...@kineticode.com 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
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
On Mon, Apr 25, 2011 at 12:17 PM, David E. Wheeler da...@kineticode.com 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
Daniele Varrazzo daniele.varra...@gmail.com writes:
On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us 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
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
David E. Wheeler da...@kineticode.com 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.
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 should be
On Sun, Apr 24, 2011 at 10:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniele Varrazzo daniele.varra...@gmail.com writes:
On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
If you did not actually change the contents of the install script, you
should not change its version
David E. Wheeler da...@kineticode.com 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
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 minor
Daniele Varrazzo daniele.varra...@gmail.com 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
On Thu, Apr 21, 2011 at 4:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com 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
On Apr 23, 2011, at 1:03 PM, Dimitri Fontaine wrote:
Daniele Varrazzo daniele.varra...@gmail.com 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
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:
On Thu, Apr 21, 2011 at 1:14 AM, David E. Wheeler da...@kineticode.com 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;
David E. Wheeler da...@kineticode.com 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
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 me.
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
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
version
38 matches
Mail list logo
