On Thu, Feb 3, 2011 at 4:24 PM, Josh Berkus j...@agliodbs.com wrote:
So every package would include a script called upgrade.sql ( or
upgrade.c? ) which is supposed to handle the upgrade, and it's up to the
module author to power that, at least until 9.2? Seem like the most
reasonable course
Robert Haas robertmh...@gmail.com writes:
I don't think we should commit something that for 9.1 that we may need
to change incompatibly for 9.2. If we're not completely happy with
it, it gets booted. Whatever we put in place here is going to be with
us for a long, long time.
So, what is it
On Fri, Feb 4, 2011 at 10:13 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
I don't think we should commit something that for 9.1 that we may need
to change incompatibly for 9.2. If we're not completely happy with
it, it gets booted. Whatever we
On Feb 4, 2011, at 7:48 AM, Robert Haas wrote:
I'd like to answer this question, but I have not had enough time to
read through this patch in detail, because there are 97 patches in
this CommitFest. The point I'm trying to make, however, is
procedural. We shouldn't commit anything at the
On Fri, Feb 4, 2011 at 11:48 AM, David E. Wheeler da...@kineticode.com wrote:
Robert, I think that the core extension if pretty uncontroversial, modulo
some minor issues. It's the upgrade process that's more controversial. I
think the case can be made to accept even that part as Dim has
On Feb 4, 2011, at 8:54 AM, Robert Haas wrote:
Yeah, I understand. I believe Tom said he was going to look at the
basic functionality with an eye toward commit, and I hope to look at
it as well, either before or after it gets committed. Time
permitting, I'd then like to look at this, but
David E. Wheeler da...@kineticode.com writes:
Dim, I haven't followed that closely lately, but is the ALTER
EXTENSION UPGRADE bit still a separate patch?
Yes it is. It's an incremental that apply on top of the extension patch
and get its own patch entry on the commit fest application:
On 02/02/2011 08:22 PM, Dimitri Fontaine wrote:
Either one line in the Makefile or a new file with the \i equivalent
lines, that would maybe look like:
SELECT pg_execute_sql_file('upgrade.v14.sql');
SELECT pg_execute_sql_file('upgrade.v15.sql');
So well… I don't see how you've made it
On 02/03/2011 12:23 AM, Robert Haas wrote:
[..]
-- unconditional stuff
[..6]
-- stuff to do if coming from pre-7
[..]
-- some more unconditional stuff
[6..12]
-- stuff to do if coming from between 6 and 12
[..]
-- a few more unconditional things
This might be a stupid idea, but how about
Robert Haas robertmh...@gmail.com writes:
Stepping back from the implementation details and file naming
conventions a bit, it seems to me that when you do schema upgrades,
there are basically three possible things you might want to put in the
upgrade script:
[...]
I've managed schema upgrades
Anssi Kääriäinen anssi.kaariai...@thl.fi writes:
upgrade_from_2.0.sql contents:
alter table foobar add column id3 integer;
pg_execute_extension_file('upgrade_from_3.0.sql');
...
So, when creating a new version you would need to update the main .sql file,
create a new upgrade file, and
This might be a silly idea, but I'm not sure if it was really
discussed with respect to extensions here before...
Why not use PL/pgSQL as install/upgrade script language,
specially now when it's included in the core by default?
This would allow for relatively straightforward inclusion
of
On Thu, Feb 03, 2011 at 10:21:28AM +0200, Anssi Kääriäinen wrote:
On 02/02/2011 08:22 PM, Dimitri Fontaine wrote:
Either one line in the Makefile or a new file with the \i equivalent
lines, that would maybe look like:
SELECT pg_execute_sql_file('upgrade.v14.sql');
SELECT
On Thu, Feb 3, 2011 at 9:53 AM, Ross J. Reedstrom reeds...@rice.edu wrote:
Example:
upgrade_from_1_0 = '1.0 = upgrade_from_1.0.sql'
upgrade_from_2_0 = '2.0 = upgrade_from_2.0.sql'
upgrade_from_3_0 = '3.0 = upgrade_from_3.0.sql'
Hmm, how about allowing a list of files to execute? That allows
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, how about allowing a list of files to execute? That allows the
Sure. I still don't see why doing it in the control file is better than
in the Makefile, even if it's already better than in the SQL script, at
least in terms of code to write to
On Thu, Feb 03, 2011 at 04:31:08PM +0100, Dimitri Fontaine wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, how about allowing a list of files to execute? That allows the
Sure. I still don't see why doing it in the control file is better than
in the Makefile, even if it's already
On Thu, Feb 3, 2011 at 11:25 AM, Ross J. Reedstrom reeds...@rice.edu wrote:
Speaking about which, using Make rules to prepare your upgrade files
from other pieces means no development at all on the backend side. You
can hardly beat that.
Yes, from the backend-developer's perspective. But not
=?iso-8859-2?Q?=AEiga_Kranjec?= z...@ljudmila.org writes:
This might be a silly idea, but I'm not sure if it was really
discussed with respect to extensions here before...
yes, it was ...
Why not use PL/pgSQL as install/upgrade script language,
specially now when it's included in the core
Robert Haas robertmh...@gmail.com writes:
Yes, from the backend-developer's perspective. But not from the
extension-developer's perspective :-) And seriously, make is one of
those things that is supremely capable of doing lots of stuff, but is so
difficult to use correctly that everyone keeps
On Feb3, 2011, at 16:31 , Dimitri Fontaine wrote:
Ross J. Reedstrom reeds...@rice.edu writes:
Hmm, how about allowing a list of files to execute? That allows the
Sure. I still don't see why doing it in the control file is better than
in the Makefile, even if it's already better than in the
On Thu, Feb 3, 2011 at 11:53 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Yes, from the backend-developer's perspective. But not from the
extension-developer's perspective :-) And seriously, make is one of
those things that is supremely capable
Florian Pflug f...@phlo.org writes:
I fully agree. The extension infrastructure should provide basic support
for upgrades, not every kind of bell and whistle one could possible think of.
Maybe somewhere around here we should stop and ask why we are bothering
with any of this. The original idea
On Feb 3, 2011, at 9:38 AM, Tom Lane wrote:
Given that pg_upgrade is now considered a supported piece of the system,
ISTM that most real-world upgrade scenarios will be accomplished with
pg_upgrade relying on provision (3). It looks to me like we're talking
about adding a large amount of
On Thu, Feb 3, 2011 at 12:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
I fully agree. The extension infrastructure should provide basic support
for upgrades, not every kind of bell and whistle one could possible think of.
Maybe somewhere around here we should
On Feb 3, 2011, at 9:54 AM, Robert Haas wrote:
I think you can pretty much take it to the bank that there will be
demand. This is an important, real-world problem.
That having been said, I'm not 100% convinced that the main extensions
patch is ready for prime-time, and I'm even less
David E. Wheeler da...@kineticode.com writes:
I think we will need to come back to it before, long, however, because many
extensions are released far more often than major versions of PostgreSQL. So
while one might run pg_upgrade, at most, about once every 12-18 months, they
will often want
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install a newer
version of an extension. Admittedly, this is swinging a rather larger
hammer than apply an upgrade script
Tom Lane t...@sss.pgh.pa.us writes:
Maybe somewhere around here we should stop and ask why we are bothering
with any of this. The original idea for an extension concept was that
(1) some collection of objects could be designated as a module
(2) pg_dump would be taught to dump LOAD MODULE foo
Tom Lane t...@sss.pgh.pa.us writes:
Now having said that, it does occur to me that there is an upgrade-ish
scenario that every user is going to hit immediately, which is how to
get from an existing installation with a pile of loose objects created
by one or more contrib modules to a state
On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install a newer
version of an extension.
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install
On Feb 3, 2011, at 11:02 AM, Tom Lane wrote:
That's putting it mildly. It's more like sending a rocket into outer
space to tweak the orbit of a comet so that it crashes into your
barbecue grill to light a fire so you can roast marshmallows.
LOL.
No, it's more like using a sledgehammer to
On Thu, Feb 3, 2011 at 2:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 3, 2011 at 1:10 PM, David E. Wheeler da...@kineticode.com
wrote:
On Feb 3, 2011, at 10:07 AM, Tom Lane wrote:
Well, pg_upgrade is designed to work within a major-version
All,
Let me summarize the prospective solutions based on some chatting with
some potential extension authors (that is, folks who maintain in-house
stuff they're thinking of offering as extensions). Especially since I
think at this point the majority of -hackers has lost track of the argument:
Josh Berkus j...@agliodbs.com writes:
Let me summarize the prospective solutions based on some chatting with
some potential extension authors (that is, folks who maintain in-house
stuff they're thinking of offering as extensions). Especially since I
think at this point the majority of
Well if you want to support upgrades between each two versions, that
means you have users and you don't know what they currently have
installed. Then you have this problem to solve, and it's complex the
same no matter what tools are offered.
How *are* we detecting which version is
Josh Berkus j...@agliodbs.com writes:
(D) Requires a series of ordered upgrade scripts in sortable version
numbering, each of which gets applied in order between the two versions.
This initially seems like the most attractive option -- and is the one
used by dozens of popular open source web
On Feb 3, 2011, at 11:35 AM, Josh Berkus wrote:
(D) Requires a series of ordered upgrade scripts in sortable version
numbering, each of which gets applied in order between the two versions.
This initially seems like the most attractive option -- and is the one
used by dozens of popular open
FWIW, I think that last objection is bogus. There's no reason that an
extension author can't leave dummy C functions in his code to support
obsolete CREATE FUNCTION calls. (As an example, I added one to
Alexander Korotkov's recent pg_trgm patch. It consists of 10 lines of
boilerplate
On Wed, Feb 2, 2011 at 03:21, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
PFA version 3 of the ALTER EXTENSION PATCH, cleaned and merged against
recent HEAD and extension's branch from which I just produced the v30
patch.
Excuse me for asking, but could you explain what is the purpose?
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Excuse me for asking, but could you explain what is the purpose?
Which is true, upgrade to 9.1 from past versions or upgrade
from 9.1 to future versions? Also, how much advantage will we
have compared with uninstall_MODULE.sql + CREATE
Itagaki Takahiro itagaki.takah...@gmail.com writes:
The latest extension might drop some functions.
Then the upgrade script contains the DROP commands.
I'm still not clear what upgrade means. if module authors wrote
functions with C, they can just replace .so to upgrade. If with
SQL or
On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:
Well, you write 3 scripts.
Let's consider an example, the lo contrib, with its 3 objects:
CREATE DOMAIN lo AS pg_catalog.oid;
CREATE OR REPLACE FUNCTION lo_oid(lo) …
CREATE OR REPLACE FUNCTION lo_manage() …
Now, the upgrade script
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2011, at 6:45 AM, Dimitri Fontaine wrote:
Well, you write 3 scripts.
Let's consider an example, the lo contrib, with its 3 objects:
CREATE DOMAIN lo AS pg_catalog.oid;
CREATE OR REPLACE FUNCTION lo_oid(lo) …
CREATE OR REPLACE
On Feb 2, 2011, at 9:03 AM, Dimitri Fontaine wrote:
Well, fair enough I suppose. Or it would be if you gave me an
alternative that provides a simpler way to support those 3 upgrades.
I did: a naming convention with upgrade scripts that have the version number in
them. You rejected it.
Of
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2011, at 9:03 AM, Dimitri Fontaine wrote:
Well, fair enough I suppose. Or it would be if you gave me an
alternative that provides a simpler way to support those 3 upgrades.
I did: a naming convention with upgrade scripts that have the
On Feb 2, 2011, at 9:19 AM, Dimitri Fontaine wrote:
I see there no solution to your reaction here. Please take the time to
tell us more about what exactly it is that you hated, and how to make it
lovely. We won't make any progress with your current commenting style.
Here is your example of
David E. Wheeler da...@kineticode.com writes:
They are identical except for the extra line in the second one. If I
had, say 15 different versions of an extension, then I'd have 15
upgrade scripts. That's fine. But in your plan, the script to upgrade
from version 1 to version 15 would have all
On Feb 2, 2011, at 10:04 AM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
They are identical except for the extra line in the second one. If I
had, say 15 different versions of an extension, then I'd have 15
upgrade scripts. That's fine. But in your plan, the script
David E. Wheeler da...@kineticode.com writes:
upgrade.null-v15.sql: upgrade.v14.sql upgrade.v15.sql
cat upgrade.v14.sql upgrade.v15.sql $@
Sure, if you know Make really well. But then I need to add a line to
the Makefile for every bloody upgrade script. Gross.
Either one line in the
On Feb 2, 2011, at 10:14 AM, Aidan Van Dyk wrote:
My concern with this approach (upgrade is forced through all
intermetiary versions) is that the shared libray now for version 15
*has* to have all the intermediary compatibility for *all* versions
in it. So it has to have functions with all
On Feb 2, 2011, at 10:22 AM, Dimitri Fontaine wrote:
Either one line in the Makefile or a new file with the \i equivalent
lines, that would maybe look like:
SELECT pg_execute_sql_file('upgrade.v14.sql');
SELECT pg_execute_sql_file('upgrade.v15.sql');
So well… I don't see how you've
David E. Wheeler da...@kineticode.com writes:
On Feb 2, 2011, at 10:14 AM, Aidan Van Dyk wrote:
My concern with this approach (upgrade is forced through all
intermetiary versions) is that the shared libray now for version 15
*has* to have all the intermediary compatibility for *all* versions
On Wed, Feb 2, 2011 at 12:31 PM, David E. Wheeler da...@kineticode.com wrote:
They are identical except for the extra line in the second one. If I had, say
15 different versions of an extension, then I'd have 15 upgrade scripts.
That's fine. But in your plan, the script to upgrade from
On Wed, Feb 2, 2011 at 12:31 PM, David E. Wheeler da...@kineticode.com wrote:
They are identical except for the extra line in the second one. If I had, say
15 different versions of an extension, then I'd have 15 upgrade scripts.
That's fine. But in your plan, the script to upgrade from
Aidan Van Dyk ai...@highrise.ca writes:
My concern with this approach (upgrade is forced through all
intermetiary versions) is that the shared libray now for version 15
*has* to have all the intermediary compatibility for *all* versions
in it. So it has to have functions with all symbols so
Hi,
PFA version 3 of the ALTER EXTENSION PATCH, cleaned and merged against
recent HEAD and extension's branch from which I just produced the v30
patch.
It includes a way to upgrade from null, that is from pre-9.1, and the
specific upgrade files to achieve that for all contribs. That goes like
David Fetter da...@fetter.org writes:
One could imagine that an extension was updated more quickly than
PostgreSQL major versions come out, or at least not at the exact same
time.
Sure, but I don't see what your proposed syntax is giving us here.
Currently the new version you're upgraded to is
On Wed, Jan 05, 2011 at 10:19:23AM +0100, Dimitri Fontaine wrote:
David Fetter da...@fetter.org writes:
One could imagine that an extension was updated more quickly than
PostgreSQL major versions come out, or at least not at the exact same
time.
Sure, but I don't see what your proposed
David Fetter da...@fetter.org writes:
The syntax by itself does nothing, but the underlying capability gives
users:
Ok, now I understand that the syntax you proposed was a shortcut for an
I-want-it-all request :)
- The ability to have versions of software on different databases on
the same
Hi,
Please find attached the patch to support ALTER EXTENSION UPGRADE,
following exchanges made on this list — we can't really speak about
decisions here, apparently, until commit is done :)
The documentation is available online for easy browsing here:
On Tue, Jan 04, 2011 at 12:31:55PM +0100, Dimitri Fontaine wrote:
Hi,
Please find attached the patch to support ALTER EXTENSION UPGRADE,
Do you plan to have
ALTER EXTENSION ... UPGRADE TO VERSION ...
, or the more general,
ALTER EXTENSION ... ALTER VERSION TO ... ?
I get that this might
David Fetter da...@fetter.org writes:
Do you plan to have
ALTER EXTENSION ... UPGRADE TO VERSION ...
, or the more general,
ALTER EXTENSION ... ALTER VERSION TO ... ?
Well why not, but I'm not sure I understand what you have in mind here.
I don't exactly see how to install more than one
On Tue, Jan 04, 2011 at 08:31:19PM +0100, Dimitri Fontaine wrote:
David Fetter da...@fetter.org writes:
Do you plan to have
ALTER EXTENSION ... UPGRADE TO VERSION ...
, or the more general,
ALTER EXTENSION ... ALTER VERSION TO ... ?
Well why not, but I'm not sure I understand
On Sat, Dec 11, 2010 at 4:35 PM, David E. Wheeler da...@kineticode.com wrote:
What about having the following keys supported in the control file:
upgrade_version = 'script.version.sql'
upgrade_all = 'script.sql'
Why not just use an upgrade script naming convention? Think: Convention over
Aidan Van Dyk ai...@highrise.ca writes:
Mainly, because of the situation where I have may versions that can
all be upgraded from the same script. I'ld much rather distribution
just 3 scripts (install + 2 upgrades), and a control file with
something like this (pretend I'm on version 2.6)
On Mon, Dec 13, 2010 at 9:55 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Again, I'ld love for the version to support some sort of prefix or
wildcard matching, so I could do:
upgrade-1.* = $EXT-upgrade-1.sql
upgrade-2.* = $EXT-upgrade-2.sql
Problem is: what to do if a single
Aidan Van Dyk ai...@highrise.ca writes:
On Sat, Dec 11, 2010 at 4:35 PM, David E. Wheeler da...@kineticode.com
wrote:
Why not just use an upgrade script naming convention?
Mainly, because of the situation where I have may versions that can
all be upgraded from the same script. I'ld much
Excerpts from Tom Lane's message of lun dic 13 12:50:43 -0300 2010:
I see no advantage of this over a script per version combination, so
long as you allow scripts to \include each other.
Hmm, are the upgrade scripts going to be run via SPI?
--
Álvaro Herrera alvhe...@commandprompt.com
The
Tom Lane t...@sss.pgh.pa.us writes:
I see no advantage of this over a script per version combination, so
long as you allow scripts to \include each other.
I guess the following should do:
SELECT pg_execute_sql_file('upgrade-1.sql');
But I rather prefer the 2-liner control file, myself:
Hi,
I've been reading through the entire thread and it seems like this is
the best mail to choose to answer.
Tom Lane t...@sss.pgh.pa.us writes:
Maybe I misread David's meaning, but I thought he was saying that
there's no value in inventing all those control file entries in the
first place.
On Dec 11, 2010, at 12:09 PM, Dimitri Fontaine wrote:
Yeah that works, as soon as VVV is the version we upgrade from.
That said, we need to find a way to lighten the process for extensions
where it's easy to have a single script to support upgrade from more
than once past release.
What
On 12/10/10 12:17 PM, Dimitri Fontaine wrote:
Or do we want contrib's specific version numbers that are not all the
same as the current PostgreSQL version number?
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Also, once
Josh Berkus j...@agliodbs.com writes:
On 12/10/10 12:17 PM, Dimitri Fontaine wrote:
Or do we want contrib's specific version numbers that are not all the
same as the current PostgreSQL version number?
I think that each contrib needs its own version numbers. The reason
being that most minor
Josh Berkus j...@agliodbs.com writes:
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Fair enough. What are the version numbers of each current contribs?
Also, once extensions and pgxn are operating full swing, I see
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite skeptical about it. Quite
apart from anything else we should keep enough extensions in core to
test the
On Fri, 2010-12-10 at 15:42 -0500, Andrew Dunstan wrote:
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite skeptical about it. Quite
apart from anything
Joshua D. Drake j...@commandprompt.com writes:
On Fri, 2010-12-10 at 15:42 -0500, Andrew Dunstan wrote:
On 12/10/2010 03:24 PM, Josh Berkus wrote:
Also, once extensions and pgxn are operating full swing, I see contrib
going away anyway ...
We've heard this before, but I'm still quite
Tom Lane t...@sss.pgh.pa.us writes:
I don't believe that extension SQL scripts should rely on DO blocks.
There is no requirement that plpgsql be installed, and we're not going
to create one as part of this feature. What this means is that the
design you offer above doesn't work at all, since
On 12/10/10 12:34 PM, Dimitri Fontaine wrote:
Josh Berkus j...@agliodbs.com writes:
I think that each contrib needs its own version numbers. The reason
being that most minor updates don't touch contrib.
Fair enough. What are the version numbers of each current contribs?
I'd say that for
Josh Berkus j...@agliodbs.com writes:
The alternative would be to match postgresql minor version numbering
exactly, and then come up with some way to have a no-op upgrade in the
frequent cases where the contrib module isn't changed during a minor
release. This would also require some kind of
On Fri, Dec 10, 2010 at 4:50 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Now, what about having the control file host an 'upgrade' property where
to put the script name? We would have to support a way for this filename
to depend on the already installed version, I'm thinking that %v
On Dec 10, 2010, at 1:55 PM, Josh Berkus wrote:
I'd say that for anything in /contrib, it gets a new version with each
major version of postgresql, but not with each minor version. Thus,
say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
fix a bug in dblink, then it
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
(Actually, we could probably assume that the target version is
implicitly the current version, as identified from the control file,
and omit that from the script file names. That would avoid ambiguity
if version numbers can have more than
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
I don't think we can safely design around one part version numbers here,
because I'm yet to see that happening in any extension I've had my hands
on, which means a few already, as you can
On Dec 10, 2010, at 2:32 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
I don't think we can safely design around one part version numbers here,
because I'm yet to see that happening in any extension I've had my
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 1:50 PM, Dimitri Fontaine wrote:
(Actually, we could probably assume that the target version is
implicitly the current version, as identified from the control file,
and omit that from the script file names. That would avoid
David E. Wheeler da...@kineticode.com writes:
You keep making extension authors have to do more work. I keep trying
to make it so they can do less. We want the barrier to be as low as
possible, which means a lot of DRY. Make it *possible* to do more
complicated things, but don't *require* it.
Josh Berkus j...@agliodbs.com writes:
I'd say that for anything in /contrib, it gets a new version with each
major version of postgresql, but not with each minor version. Thus,
say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we
fix a bug in dblink, then it becomes dblink
On Dec 10, 2010, at 2:40 PM, Tom Lane wrote:
Since you know the existing version number, you just run all that come
after. For example, if the current version is 1.12, then you know to run
foo-1.13.sql and foo-1.15.sql.
If we assume the target is the current version, then we only need the
On Dec 10, 2010, at 2:43 PM, Dimitri Fontaine wrote:
David E. Wheeler da...@kineticode.com writes:
You keep making extension authors have to do more work. I keep trying
to make it so they can do less. We want the barrier to be as low as
possible, which means a lot of DRY. Make it *possible*
Tom Lane t...@sss.pgh.pa.us writes:
If we assume the target is the current version, then we only need the
old-version number in the file name, so it doesn't matter how many
parts it has.
IIUC, that puts even more work on the shoulders of the extension
authors, because the file named
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
David E. Wheeler da...@kineticode.com writes:
You keep making extension authors have to do more work. I keep trying
to make it so they can do less. We want the barrier to be as low as
possible, which means a lot of DRY. Make it *possible* to do
On Dec 10, 2010, at 2:55 PM, Dimitri Fontaine wrote:
Tom Lane t...@sss.pgh.pa.us writes:
If we assume the target is the current version, then we only need the
old-version number in the file name, so it doesn't matter how many
parts it has.
IIUC, that puts even more work on the shoulders of
On Dec 10, 2010, at 2:58 PM, Tom Lane wrote:
Maybe I misread David's meaning, but I thought he was saying that
there's no value in inventing all those control file entries in the
first place. Just hard-wire in ALTER EXTENSION UPGRADE the convention
that the name of an upgrade script to
David E. Wheeler da...@kineticode.com writes:
Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts are
handled: version-string-named directories with the appropriate scripts to
upgrade *to* the named version number.
But you still have to know what you're upgrading
On Dec 10, 2010, at 3:03 PM, Tom Lane wrote:
Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts
are handled: version-string-named directories with the appropriate scripts
to upgrade *to* the named version number.
But you still have to know what you're upgrading
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 3:03 PM, Tom Lane wrote:
Yeah, it should be *to* 1.12. FWIW, this is how Bricolage upgrade scripts
are handled: version-string-named directories with the appropriate scripts
to upgrade *to* the named version number.
But you
On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
Huh? It's in the pg_extension catalog.
How do you select which upgrade script to apply?
You run all those that contain version numbers higher than the
currently-installed one.
This of course assumes that one can correctly tell that one version
David E. Wheeler da...@kineticode.com writes:
On Dec 10, 2010, at 4:15 PM, Tom Lane wrote:
How do you select which upgrade script to apply?
You run all those that contain version numbers higher than the
currently-installed one.
This of course assumes that one can correctly tell that one
101 - 200 of 204 matches
Mail list logo
