On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote:
But now, let's make it harder. I've found a grave bug in 1.1, which
causes the PG backend to segfault. Easy fix, good thing, so now I
release 1.2:
Unless the bug is such that you have to change the installation script
file, there is no
Peter Eisentraut pete...@gmx.net writes:
On fre, 2011-02-11 at 14:19 -0500, Tom Lane wrote:
Unless the bug is such that you have to change the installation script
file, there is no reason to bump the version number at all. These
version numbers apply to the install SQL script, not the
Tom Lane t...@sss.pgh.pa.us writes:
My feeling about this is that we should recommend that version
identifiers be limited to ASCII letters, digits, dots, and underscore,
but assume that extension authors are adults and can grasp the risks
of using other characters. We should not be in the
Tom Lane t...@sss.pgh.pa.us writes:
Actually, I was having second thoughts about that while at dinner. What
is the value of separating the bootstrap-an-extension-from-old-objects
operation into two steps? It's certainly not convenient for users, and
I don't see that the intermediate state
Tom Lane t...@sss.pgh.pa.us writes:
First off, I don't much care for the name CREATE WRAPPER EXTENSION.
WRAPPER is a misnomer in this case --- it's not wrapping anything.
I think Dimitri stated that he chose WRAPPER just because it was an
already existing keyword, but that isn't much of an
On 02/11/2011 05:05 AM, Tom Lane wrote:
Actually, I was having second thoughts about that while at dinner. What
is the value of separating the bootstrap-an-extension-from-old-objects
operation into two steps? It's certainly not convenient for users, and
I don't see that the intermediate state
On Fri, Feb 11, 2011 at 12:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Feb 10, 2011, at 7:05 PM, Tom Lane wrote:
(I'm not wedded to the phrase FROM OLD in particular, but it does
reuse already existing keywords. Also, maybe it'd be better to
Robert Haas robertmh...@gmail.com writes:
I still think you might be over-designing this. Upgrading from the
pre-extension world doesn't need to be elegant; it just has to work.
Allow me to disagree here. The main use case is not supporting users
that upgrade with extensions to 9.1, but to
On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
I still think you might be over-designing this. Upgrading from the
pre-extension world doesn't need to be elegant; it just has to work.
Allow me to disagree here. The
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
I still think you might be over-designing this. Upgrading from the
pre-extension world doesn't need to be elegant; it just has
=?ISO-8859-1?Q?Anssi_K=E4=E4ri=E4inen?= anssi.kaariai...@thl.fi writes:
The above command assumes there is only one unpackaged version from
which users might update from. Is that what is wanted? I am wondering if
FROM OLD should be FROM OLD VERSION version (or better: FROM UNPACKAGED
Tom Lane t...@sss.pgh.pa.us writes:
CREATE EXTENSION foo [ VERSION targetversion ] [ FROM
oldversion ]
I came to the same conclusion but added my version aliases idea in
there so that it could maybe be easy for the user not to confuse
things.
I still think that free form version
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
I can already hear people wanting version aliases instead. We could
support e.g. 4 or 5 aliases like 'stable', 'support', 'alpha', 'beta'
and maybe 'experimental'. Then rather than defining current_version
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Is there a test somewhere that when CREATE OR REPLACE FUNCTION
runs from an extension's script at upgrade, the function must
already be attached to the extension if it exists in the system?
Ditto for views etc?
IIRC, the current behavior is
Tom Lane t...@sss.pgh.pa.us writes:
After a bit of reflection I think we should stick with default_version
as the parameter name in 9.1. If we want to open it up to allowing
arbitrary version aliases later, we can let it accept xxx_version as
defining an alias xxx. That seems a lot safer
Tom Lane t...@sss.pgh.pa.us writes:
1. If you pick the wrong FROM version, the upgrade script will almost
certainly fail, because the objects won't exist or won't be in the state
it expects (ie, not already members of the extension).
IIRC, the current behavior is that C.O.R.F. on an existing
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Uh, not sure how you're envisioning that working? If it fails to find
an upgrade script path from the current version to whatever is default,
it will still fail to find any path after you explicitly tell it
Tom Lane t...@sss.pgh.pa.us writes:
That's not exactly what happens here. There would be no support
version alias in the control file, so no way to upgrade to it, and
support would happen to be what ALTER EXTENSION foo UPDATE would
consider when you don't mention explicitly the target
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
If VERSION is not specified, v is taken from default_version in the
control file, or fail if that's not given either. We
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
different default version name from what CREATE EXTENSION uses (unless
Yes. I see that as a good feature to have. stable and support
On Fri, Feb 11, 2011 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
It strikes me that if you used the same options syntax
On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
different default version name from what CREATE EXTENSION uses (unless
On Feb 11, 2011, at 10:06 AM, Tom Lane wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
Hmm. To make that work, we'd have to have ALTER EXTENSION UPDATE use a
different default version name from what CREATE EXTENSION uses (unless
Yes. I see that
CREATE EXTENSION extname [ ( option [ , ... ] ) ]
where option can be one of:
SCHEMA blah
VERSION blah
FROM blah
+1
This also means that users don't have to remember the specific ordering
of the syntax, which is a big plus.
--
-- Josh Berkus
On Feb 11, 2011, at 9:35 AM, Tom Lane wrote:
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
If VERSION is not specified, v is taken from default_version in the
control
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 11, 2011 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
It strikes
David E. Wheeler da...@kineticode.com writes:
Sounds good. One nit: can't we call the line in the control file version
rather than default_version? I've been thinking of the control file as
describing a release of an extension, which of course has a version, not a
default version.
No ---
On Fri, Feb 11, 2011 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
In principle we are leaving it to the extension author to choose that.
However, we're going to have to make a choice for the contrib modules,
and I'll bet lunch that most people will follow whatever precedent we
set with
@postgresql.org
Subject: Re: [HACKERS] ALTER EXTENSION UPGRADE, v3
We will add logic to find a chain of update scripts leading from oldv to
v, in case that exact combination is not available in the extension's
script directory. (NOTE: maybe in the CREATE ... FROM case, it would be
a better idea to not do
On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:
No --- in the current vision, a control file may describe a whole
collection of versions of the same extension, and the parameter in
question is selecting the default or preferred version to install.
I'm not wedded to default_version, but I think
=?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= anssi.kaariai...@thl.fi writes:
This has the side effect that you can also have downgrade scripts. I
don't know if this is designed or just coincidental, so thought it
would be worth mentioning.
Yeah, that's intentional and IMO worth supporting.
We do
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not very happy with that at all, either as to the concept or the
specific version-alias names. I don't think that CREATE and ALTER
really need different default version targets.
On Feb 11, 2011, at 10:58 AM, Aidan Van Dyk wrote:
I release exetension afoo, initial as version 1.0. From my
understanding, it's going to contain:
afoo control file, named something particular)
- default_version = 1.0
- encoding utf8
foo-1.0.sql installstion script
and
Aidan Van Dyk ai...@highrise.ca writes:
And I now release and updated version 1.1 which fixes a problem. No problem:
afoo control file:
- default_version = 1.1
- encoding utf8
afoo-1.1.sql installation
afoo-upgrade-1.0-1.1.sql upgrade script
any required shared
On Fri, Feb 11, 2011 at 6:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No --- in the current vision, a control file may describe a whole
collection of versions of the same extension, and the parameter in
question is selecting the default or preferred version to install.
I'm not wedded to
On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This gives my first problem. I can't package afoo-2.x seperately from
afoo-1.x, because they both want to write the afoo control file.
No, you ship *one* package that supports both 1.1 and 2.0.
Hm... As an example of a
Aidan Van Dyk ai...@highrise.ca writes:
On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, you ship *one* package that supports both 1.1 and 2.0.
Hm... As an example of a project that generally has pretty good
software release practices, I'm glat that the PostgreSQL
Tom Lane t...@sss.pgh.pa.us writes:
In principle we are leaving it to the extension author to choose that.
Most extensions already have a version number. ip4r is 1.05, prefix is
1.1.0, dbi-link is 2.0.0, temporal is 20091213, tablelog is 0.4.4, etc.
All those extensions will need a newer
On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote:
It would be good to avoid regexp and globing pattern characters, I would
say.
There's the coma, as in foo,1.0,1.1.sql, so ugly that it's unused :) I
wonder if : would be good? foo:1.0:1.1.sql. A very quick test seems
to show that
On Fri, Feb 11, 2011 at 7:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If you were expecting this proposal to make things easier as far as
dealing with multiple major releases, sorry, our ambitions don't extend
that far yet.
Sorry, I might have been confusing here... I'm not talking about *PG*
David E. Wheeler da...@kineticode.com writes:
On Feb 11, 2011, at 11:50 AM, Dimitri Fontaine wrote:
It would be good to avoid regexp and globing pattern characters, I would
say.
There's the coma, as in foo,1.0,1.1.sql, so ugly that it's unused :) I
wonder if : would be good?
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
However, we're going to have to make a choice for the contrib modules,
and I'll bet lunch that most people will follow whatever precedent we
set with those. I was thinking about using either old or unpackaged.
Tom Lane t...@sss.pgh.pa.us writes:
OK, let me see if I can summarize what I think we've agreed to:
CREATE syntax is extended to
CREATE EXTENSION extname [WITH] [SCHEMA s] [VERSION v] [FROM oldv]
Agreed.
If VERSION is not specified, v is taken from default_version in the
control
On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
However, we're going to have to make a choice for the contrib modules,
and I'll bet lunch that most people will follow whatever precedent we
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I should also make clear that I intend to start out all the contrib
modules at version 1.0.
What happens if their contents change several times during a major
release cycle?
I think
Tom Lane t...@sss.pgh.pa.us writes:
I don't see that this proposal changes anything about that. It's still
the case that the underlying .so is tied to a major PG version. What
you'll ship is a control file and assorted .sql files that represent the
user APIs you are interested in supporting
Aidan Van Dyk ai...@highrise.ca writes:
So, I like that the attempt is to support multiple versions. But
unless you can manage the files (both shared libraries, and any
scripts to create/update SQL objects) for different version
independently, I can't see the multiple versions at once
Tom Lane t...@sss.pgh.pa.us writes:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Will we have to provide different upgrade scripts for different past
major versions of PostgreSQL? If so, I would say 9.0 or 8.4 would
be better names. hstore at least is an example that would need this
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
I don't see that this proposal changes anything about that. It's still
the case that the underlying .so is tied to a major PG version. What
you'll ship is a control file and assorted .sql files that represent
Tom Lane t...@sss.pgh.pa.us writes:
I think it'd likely be sufficient to bump them only once per release
cycle, ie, there's no need to distinguish versions that never appeared
in the wild. But if we forgot and created 1.1 early in the 9.2 release
cycle and 1.2 late in the cycle, there's no
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
I think it'd likely be sufficient to bump them only once per release
cycle, ie, there's no need to distinguish versions that never appeared
in the wild. But if we forgot and created 1.1 early in the 9.2
Tom Lane t...@sss.pgh.pa.us writes:
The worst case is that if you are upgrading from 1.2 to 2.0 the path
is 1.2 - 1.1 - 2.0, even if there exists a path 1.2 - 1.8 - 1.9 -
2.0. This could potentially result in data loss, if the downgrade
drops some columns or something like that.
Hmm. That
Tom Lane t...@sss.pgh.pa.us writes:
Anything that got kicked out to pgfoundry would presumably start acting
that way. Anything that's part of core git is going to stay on the same
release cycle as the core, thank you very much. Release engineering is
a big enough headache around here
Tom Lane t...@sss.pgh.pa.us writes:
I don't see what that does for you. This is still all being examined by
a particular major release of PG, so what will it do with a require that
specifies some other major release? Nothing useful. And there's a very
significant downside, which is that
David E. Wheeler da...@kineticode.com writes:
On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:
It can be specified by a directory parameter in the control file,
and defaults to the same place the control file is. Right now, that's
$PREFIX/share/contrib/.
Frankly, given the likely proliferation
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
=?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= anssi.kaariai...@thl.fi writes:
This has the side effect that you can also have downgrade scripts. I
don't know if this is designed or just coincidental, so thought it
would be worth
marcin mank marcin.m...@gmail.com writes:
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. Â That seems like it would require a rather pathological collection
of upgrade scripts. Â In particular why would you have a one-step upgrade
from 1.1 to 2.0 but no short path
I spent some time reviewing this thread. I think the major point that's
not received adequate discussion is this: the design assumes that there's
just one current version of any extension, and that's not good enough.
David Fetter was trying to make that point upthread but didn't seem to
convince
On Feb 10, 2011, at 10:26 AM, Tom Lane wrote:
1. Choose the newest available version.
2. Let the control file specify which version is the default.
I think I prefer #2 because it avoids needing a rule for comparing
version identifiers, and it caters to the possibility that the
On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
requires, relocatable and schema: These are problematic, because it's not
out of the question that someone might want to change these properties
from one version to another. But as things are currently set up, we must
know
David E. Wheeler da...@kineticode.com writes:
+1. I assume there will be some way to build versioned shared object
libraries too, then?
I'm not really addressing that in this proposal. You could imagine
supporting all the extension versions in one .so, or you could have one
per version
On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
I'm not really addressing that in this proposal. You could imagine
supporting all the extension versions in one .so, or you could have one
per version (meaning the upgrade scripts would have to CREATE OR REPLACE
all the C functions to re-point
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
requires, relocatable and schema: These are problematic, because it's not
out of the question that someone might want to change these properties
from one version to another. But as
David E. Wheeler da...@kineticode.com writes:
On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
I don't see how that affects my point? You can spell 1.0 as 0.1
and 1.1 as 0.2 if you like that kind of numbering, but I don't
see that that has any real impact. At the end of the day an author is
On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
General opinion around Red Hat is relocatable RPMs don't work. But
pushing a set of functions from one schema to another is a very much
narrower problem than what an RPM has to deal with, so I'm not convinced
that the analogy
On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Feb 10, 2011, at 11:31 AM, Tom Lane wrote:
I don't see how that affects my point? You can spell 1.0 as 0.1
and 1.1 as 0.2 if you like that kind of numbering, but I don't
see
Robert Haas robertmh...@gmail.com writes:
Now, if you want to argue that moving an extension after the fact (ALTER
EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
argue very hard. Do you want to propose ripping that out? But
relocating at first install doesn't seem
On Thu, Feb 10, 2011 at 3:33 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Now, if you want to argue that moving an extension after the fact (ALTER
EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
argue very hard. Do you want to
On Feb 10, 2011, at 12:02 PM, Tom Lane wrote:
Oh, I see, you're just saying that it's not unlikely somebody could find
himself with dozens of minor releases all being supported. Yeah, he'd
then really need to provide shortcut upgrade scripts, and
building/maintaining those would be a pain.
On Feb 10, 2011, at 12:07 PM, Robert Haas wrote:
You don't need them to be sortable. You just need them to be
comparable, and equality seems like a plenty good enough comparison
rule. You can compute the shortest chain of upgrade scripts that can
take you from the current version to the
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Now, if you want to argue that moving an extension after the fact (ALTER
EXTENSION SET SCHEMA) is so dangerous as to be useless, I wouldn't
argue very hard. Do you want to propose
On Thu, Feb 10, 2011 at 3:46 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 10, 2011, at 12:07 PM, Robert Haas wrote:
You don't need them to be sortable. You just need them to be
comparable, and equality seems like a plenty good enough comparison
rule. You can compute the shortest
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The design as I sketched it didn't need to make any assumptions at all
about the meaning of the version identifiers. But if you were willing
to assume that the identifiers are
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
I spent some time reviewing this thread. I think the major point that's
Thanks for doing that, we badly needed someone without an horse in this
race to do that and finish the design.
So I believe that it'd be a good idea if it were possible for an
Robert Haas robertmh...@gmail.com writes:
No, you have to get *those other module authors* to make *their*
extensions not relocatable so that you can depend on them.
Just tell me exactly in which world an extension's author is setting up
the dependencies in the 'required' property and yet fails
On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The design as I sketched it didn't need to make any assumptions at all
about the meaning of the version identifiers.
Tom Lane t...@sss.pgh.pa.us writes:
I don't think it's appropriate to hold extensions to a
higher standard than we do loose objects --- especially when it takes
superuser privileges to break things by moving an extension but not to
break them by moving loose objects.
FWIW, +1.
Regards,
--
On Thu, Feb 10, 2011 at 4:14 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
No, you have to get *those other module authors* to make *their*
extensions not relocatable so that you can depend on them.
Just tell me exactly in which world an
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Hmm. The problem with that is that once there are large numbers of
intermediate versions, the number of potential paths grows
exponentially.
It's certainly not exponential i.e.
On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The real issue is what happens when you want to install
extension A, which depends on extensions B, C, and D, and B, C, and D
are all in non-standard locations. Does that have any chance of
working under the system we're
On Feb 10, 2011, at 1:22 PM, Tom Lane wrote:
Well, okay, let's go with that plan then. If we don't need to assume
anything more than equality of version names being meaningful, I think
chaining update scripts automatically should solve most of the
complaints here. People who really want to
Robert Haas robertmh...@gmail.com writes:
Well, the difference is that loose objects are just on my system,
whereas extensions are supposed to work on anybody's system. I'm not
clear that it's possible to write an extension that depends on a
relocatable extension in a sensible way. If it is,
David E. Wheeler da...@kineticode.com writes:
Yes, I think that this is a great solution. I only have to create on
upgrade script for each release, and I don't have to worry about
concatenating anything or be required to change my versioning
algorithm.
You still have to make sure that the C
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Again, it's not really any different from the case where the dependent
objects are loose rather than members of an extension.
Well, the difference is that loose objects are just on my
On Feb 10, 2011, at 1:38 PM, Tom Lane wrote:
I don't deny that there are risks here. But I think the value of being
able to move an extension when it is safe outweighs the difficulty that
sometimes it isn't safe. I think we can leave making it safer as a
topic for future investigation.
On Thu, Feb 10, 2011 at 9:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the difference is that loose objects are just on my system,
whereas extensions are supposed to work on anybody's system. I'm not
clear that it's possible to write an extension that depends on a
relocatable extension in
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
David E. Wheeler da...@kineticode.com writes:
Yes, I think that this is a great solution. I only have to create on
upgrade script for each release, and I don't have to worry about
concatenating anything or be required to change my versioning
David Christensen da...@endpoint.com writes:
I assume this has already been discussed and rejected (or it wouldn't still
be an issue), but what's wrong with the equivalent of \i in the successive
.sql upgrade files? Or is the server running the scripts itself and no
equivalent include
I don't see how that affects my point? You can spell 1.0 as 0.1
and 1.1 as 0.2 if you like that kind of numbering, but I don't
see that that has any real impact. At the end of the day an author is
going to crank out a series of releases, and if he cares about people
using those releases for
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Tom Lane t...@sss.pgh.pa.us writes:
I think we should embed the version number in the script file name,
What I don't like in that is that this restrict what the version strings
can look like. In debian for example it's pretty common to use the
It seems that we've mostly got consensus on the ideas of having a separate
script file for each installable version of an extension, and for each
basic version-upgrade action, with version numbers embedded in the file
names so that the control files don't need to be involved in identifying
what's
On Feb 10, 2011, at 3:50 PM, Tom Lane wrote:
It seems that we've mostly got consensus on the ideas of having a separate
script file for each installable version of an extension, and for each
basic version-upgrade action, with version numbers embedded in the file
names so that the control
David E. Wheeler da...@kineticode.com writes:
On Feb 10, 2011, at 3:50 PM, Tom Lane wrote:
First off, I don't much care for the name CREATE WRAPPER EXTENSION.
What's the WRAPPER bit for? I've forgotten.
It's to tell it to create an empty extension in preparation for
absorbing pre-existing
On Feb 10, 2011, at 4:11 PM, Tom Lane wrote:
It's to tell it to create an empty extension in preparation for
absorbing pre-existing objects from an old-style contrib module.
See what I mean? WRAPPER is not a useful keyword here.
Reminds me of creating a shell type so you can create I/O
On Thu, Feb 10, 2011 at 6:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Since we've agreed that there should be a version-to-install option
in CREATE EXTENSION, it seems to me that a workable solution is to
have a special convention for an empty extension version name.
Let's suppose that we choose
David E. Wheeler da...@kineticode.com writes:
On Feb 10, 2011, at 4:11 PM, Tom Lane wrote:
It's to tell it to create an empty extension in preparation for
absorbing pre-existing objects from an old-style contrib module.
See what I mean? WRAPPER is not a useful keyword here.
Reminds me of
On Feb 10, 2011, at 7:05 PM, Tom Lane wrote:
I like this because (a) it's one less step, and one less concept for
users to deal with, and (b) it's much harder to screw up. If you forget
FROM OLD when you needed it, the CREATE will fail with object already
exists errors. If you use FROM OLD
David E. Wheeler da...@kineticode.com writes:
On Feb 10, 2011, at 7:05 PM, Tom Lane wrote:
(I'm not wedded to the phrase FROM OLD in particular, but it does
reuse already existing keywords. Also, maybe it'd be better to reserve
a version string such as old or bootstrap, so that the bootstrap
On Feb 10, 2011, at 9:15 PM, Tom Lane wrote:
Hmm, you're right. The word bootstrap implies that we're starting from
nothing, which is exactly what we're *not* doing (starting from nothing
is the easy clean install case). By the same token, FROM NOTHING
isn't the right phrase either. An
Josh Berkus j...@agliodbs.com writes:
How *are* we detecting which version is installed, anyway? Is that in
the pg_extenstions table?
The installed version is in the pg_extenstion catalog, the version we're
upgrading to is in the control file and can be seen in the system view
1 - 100 of 156 matches
Mail list logo
