Peter Eisentraut 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
>> underlying .s
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, the
marcin mank writes:
> On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane 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 from 1.2?
> Say we have 20 versions
On Fri, Feb 11, 2011 at 8:15 PM, Tom Lane wrote:
> =?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= 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.
>> The worst case is that
"David E. Wheeler" 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 of upgra
Tom Lane 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 this takes us righ
Tom Lane 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 already.
Yeah, I shou
Tom Lane 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 seems
Dimitri Fontaine writes:
> Tom Lane 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 cyc
Tom Lane 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 great harm done e
Dimitri Fontaine writes:
> Tom Lane 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 interest
Tom Lane writes:
> Dimitri Fontaine 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
>> treatment I guess.
>
> I don't f
Aidan Van Dyk 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" capabilites
> that
Tom Lane 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 on that major P
Robert Haas writes:
> On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane 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 it'd likely be sufficient to bum
On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane 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 eit
Tom Lane 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 file, or fail i
Dimitri Fontaine writes:
> Tom Lane 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".
>> Thoughts?
> Will we have
"David E. Wheeler" 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? "foo:1.0:1.1.sql". A
On Fri, Feb 11, 2011 at 7:49 PM, Tom Lane 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*
major releases.
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 t
Tom Lane 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 'extension' release to s
Aidan Van Dyk writes:
> On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane 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 project
> doesn't operate this way.
On Fri, Feb 11, 2011 at 7:19 PM, Tom Lane 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 project that gen
On Fri, Feb 11, 2011 at 6:30 PM, 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
Aidan Van Dyk 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 libraries for afo
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
Robert Haas writes:
> On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane 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. And those choices of
>> names car
=?iso-8859-1?Q?K=E4=E4ri=E4inen_Anssi?= 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 have to be sure that t
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 t
@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 n
On Fri, Feb 11, 2011 at 1:30 PM, Tom Lane 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 those. I was thinki
"David E. Wheeler" 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 --- in the curre
Robert Haas writes:
> On Fri, Feb 11, 2011 at 12:35 PM, 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]
> It strikes me that if you used the sam
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
>
> 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 10:06 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane 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. s
On Fri, Feb 11, 2011 at 1:06 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Tom Lane 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.
On Fri, Feb 11, 2011 at 12:35 PM, 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]
It strikes me that if you used the same options syntax here that we're
Dimitri Fontaine writes:
> Tom Lane 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 looks
> like good default aliases for
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 create
Tom Lane 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 version.
>
>>
Dimitri Fontaine writes:
> Tom Lane 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 you
>> want to upgrade to that versi
Tom Lane 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 function
>
Tom Lane 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 than interpr
Dimitri Fontaine 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 that C.O.R.F. on an
Dimitri Fontaine writes:
> Tom Lane 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"
>>> authors would define any se
Tom Lane 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 aliases and some de
=?ISO-8859-1?Q?Anssi_K=E4=E4ri=E4inen?= 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
> VERSION version). This wou
Robert Haas writes:
> On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine
> wrote:
>> Robert Haas 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.
> Sure, but
On Fri, Feb 11, 2011 at 9:00 AM, Dimitri Fontaine
wrote:
> Robert Haas 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
>
Robert Haas 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 allow people working o
On Fri, Feb 11, 2011 at 12:15 AM, Tom Lane wrote:
> "David E. Wheeler" 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 s
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 w
Tom Lane 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 excuse.
Let's g
Tom Lane 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 with an empty ext
Tom Lane 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 business of trying
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. A
"David E. Wheeler" 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
>> scr
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
"David E. Wheeler" 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 creating a "s
On Thu, Feb 10, 2011 at 6:50 PM, Tom Lane 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 the empty st
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 f
"David E. Wheeler" 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 objects from an
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 f
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 w
Dimitri Fontaine writes:
> Tom Lane 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 ~
> separator, because 1.0~alpha1 <
>> 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 t
David Christensen 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 feature exists in r
Dimitri Fontaine writes:
> "David E. Wheeler" 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 mak
On Thu, Feb 10, 2011 at 9:38 PM, Tom Lane 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 a sensible
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.
>
Robert Haas writes:
> On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane 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 system,
> whereas extensions ar
"David E. Wheeler" 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 code remains com
Robert Haas 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, objection
> withd
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
On Thu, Feb 10, 2011 at 3:52 PM, Tom Lane 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 proposing?
>
>
Robert Haas writes:
> On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane 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. O(2^n) or something of that form.
>
On Thu, Feb 10, 2011 at 4:14 PM, Dimitri Fontaine
wrote:
> Robert Haas 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 depend
Tom Lane 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,
--
Dimitri Fontaine
On Thu, Feb 10, 2011 at 3:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane 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
Robert Haas 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 to realise
that tho
Hi,
Tom Lane 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 extension
> author to
Robert Haas writes:
> On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane 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 comparable/sortable by some rule,
> You
On Thu, Feb 10, 2011 at 3:46 PM, David E. Wheeler 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 chain of upgr
Robert Haas writes:
> On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane 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 ripping that out? But
>> relocating
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
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 Thu, Feb 10, 2011 at 3:33 PM, Dimitri Fontaine
wrote:
> Robert Haas 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
>>
Robert Haas 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 horrible.
Either an
On Thu, Feb 10, 2011 at 3:02 PM, Tom Lane wrote:
> "David E. Wheeler" 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
On Thu, Feb 10, 2011 at 2:42 PM, Tom Lane 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 holds.
>
> Now
"David E. Wheeler" 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
>> goin
Robert Haas writes:
> On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane 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 mus
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
"David E. Wheeler" 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 (meaning the upgrade sc
On Thu, Feb 10, 2011 at 1:26 PM, Tom Lane 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 these things befo
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
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
"David E. Wheeler" 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:
https://commitfest.pos
1 - 100 of 205 matches
Mail list logo
