On Jan 3, 2011, at 11:51 AM, Tom Lane wrote:
> 1. Doesn't work if you're upgrading an installation that has more than
> one database using the extension. There's only one library directory.
>
> 2. Not possible from a permissions standpoint. Even if you think it'd
> be smart to have the postgres
"David E. Wheeler" writes:
> On Jan 3, 2011, at 11:42 AM, Tom Lane wrote:
>> ... that flat out doesn't work. If the upgrade script tries to add
>> functions that didn't exist in the old .so, it'll fail.
> Right, what I'm saying is that `ALTER EXTENSION foo UPGRADE;` should install
> the .so, to
On Jan 3, 2011, at 11:42 AM, Tom Lane wrote:
> It is, but I don't see any alternative. As Dimitri said, the .so will
> typically be installed by a packaging system, so we don't have any
> opportunity to run SQL code beforehand. In any case ...
>
>> The new .so should not be installed until the
"David E. Wheeler" writes:
> On Dec 29, 2010, at 2:01 PM, Dimitri Fontaine wrote:
>> At the time you tell PostgreSQL about the new extension, the shared
>> object file has been in place for some time already, and the upgrade SQL
>> script has not been ran yet.
> That sounds dangerous.
It is, but
On Dec 29, 2010, at 2:01 PM, Dimitri Fontaine wrote:
># lo
>comment = 'managing Large Objects'
>version = '9.1devel'
>relocatable = true
>upgrade_from_null = 'null => lo.upgrade.sql'
>
> Here, any property that begins with 'upgrade_from_' is considered as an
> upgrade setup an
Robert Haas writes:
> On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane wrote:
>> We had a long discussion upthread of what version numbers to keep where.
>> IMHO the Makefile is about the *least* useful place to put a version
>> number; the more so if you want more than one. What we seem to need is
>>
On Dec 29, 2010, at 1:27 PM, Robert Haas wrote:
> I think there are really two tasks here:
>
> 1. Identify whether a newer set of SQL definitions than the one
> installed is available. If so, the extension is a candidate for an
> upgrade.
>
> 2. Identify whether the installed version of the SQL
On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> Oleg Bartunov wrote:
>>> it's clear we need versions, probably, major.minor would be enough. The
>>> problem
>>> I see is how to keep .so in sync with .sql ? Should we store .sql in
>>> database ?
>
>> Don't people norm
On Dec 29, 2010, at 12:23 PM, Tom Lane wrote:
> We had a long discussion upthread of what version numbers to keep where.
> IMHO the Makefile is about the *least* useful place to put a version
> number; the more so if you want more than one. What we seem to need is
> a version number in the .sql f
Bruce Momjian writes:
> Oleg Bartunov wrote:
>> it's clear we need versions, probably, major.minor would be enough. The
>> problem
>> I see is how to keep .so in sync with .sql ? Should we store .sql in
>> database ?
> Don't people normally define the version number in the Makefile and pass
> t
On Dec 29, 2010, at 12:00 PM, Bruce Momjian wrote:
> Don't people normally define the version number in the Makefile and pass
> the version string into the C code and perhaps a psql variable?
There is no standard pattern AFAIK. A best practice would be welcome here.
David
--
Sent via pgsql-hac
Oleg Bartunov wrote:
> Hi there,
>
> it's clear we need versions, probably, major.minor would be enough. The
> problem
> I see is how to keep .so in sync with .sql ? Should we store .sql in database
> ?
>
> Also, we need permissions for extension, since we have open/closed
> extensions.
>
Do
Hi there,
it's clear we need versions, probably, major.minor would be enough. The problem
I see is how to keep .so in sync with .sql ? Should we store .sql in database ?
Also, we need permissions for extension, since we have open/closed
extensions.
Oleg
On Sat, 11 Dec 2010, David E. Wheeler
On Dec 11, 2010, at 1:09 PM, David Fetter wrote:
>> Why is it in the makefile at all? If the makefile does need to know it,
>> why don't we have it scrape the number out of the control file? Or even
>> more to the point, since when do we need version numbers in extensions?
>
> We *absolutely* n
On Fri, Dec 10, 2010 at 11:24:27AM -0500, Tom Lane wrote:
> Dimitri Fontaine writes:
> > Tom Lane writes:
> >> Are there any actual remaining use-cases for that sed step?
>
> > The goal here is to allow extension authors to maintain their version
> > number in the Makefile rather than in the Mak
Dimitri Fontaine writes:
> On to your question about the upgrade design, in order not to paint
> ourselves into a corner. What I now have in mind is the following:
> When there's an extension upgrade the user will have to install the new
> files (.so, .sql, .control) and run an upgrade command in
Tom Lane writes:
> Why would you choose to maintain it in the Makefile? In most cases
> makefiles are the least likely thing to be changing during a minor
> update.
I must have a packager skewed view of things here, but ok, point noted.
> I would think that the right place for it is in the C c
On Dec 10, 2010, at 11:47 AM, Tom Lane wrote:
> Why would you choose to maintain it in the Makefile? In most cases
> makefiles are the least likely thing to be changing during a minor
> update. I would think that the right place for it is in the C code
> (if we're trying to version .so files) or
Dimitri Fontaine writes:
> Tom Lane writes:
>> This doesn't answer my question of why it couldn't be done the other
>> way. Why does the makefile need to know it? If it does need to know
>> it, couldn't it get it out of the control file instead of vice versa?
> Well the Makefile support is jus
"David E. Wheeler" writes:
> On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
>> Upgrade are left for a future patch, did we decide. Still, it seems to
>> me that we will support some upgrade scripts so that author can decide
>> what to do knowing current and next version, and yes, knowing th
On Dec 10, 2010, at 11:28 AM, Dimitri Fontaine wrote:
> Well the Makefile support is just a facility to fill in the control file
> automatically for you, on the grounds that you're probably already
> maintaining your version number in the Makefile. Or that it's easy to
> get it there, as in:
>
>
Tom Lane writes:
> This doesn't answer my question of why it couldn't be done the other
> way. Why does the makefile need to know it? If it does need to know
> it, couldn't it get it out of the control file instead of vice versa?
Well the Makefile support is just a facility to fill in the contr
On Dec 10, 2010, at 10:20 AM, Tom Lane wrote:
> True. Consider a situation like an RPM upgrade: it's going to drop in a
> new .so version, *and nothing else*. It's pure fantasy to imagine that
> the RPM script is going to find all your databases and execute some SQL
> commands against them. Sin
Robert Haas writes:
> On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane wrote:
>> ... In particular, keeping the
>> version number in the system catalogs seems pretty dubious. The common
>> method for upgrading an already-installed contrib module just involves
>> dropping in a new .so --- that's not go
On Fri, Dec 10, 2010 at 12:30 PM, Tom Lane wrote:
> I'm not convinced that this is actually a requirement, or that doing it
> this specific way is a good solution. In particular, keeping the
> version number in the system catalogs seems pretty dubious. The common
> method for upgrading an alread
On Dec 10, 2010, at 7:32 AM, Tom Lane wrote:
> Are there any actual remaining use-cases for that sed step? It's
> certainly vestigial as far as the contrib modules are concerned:
> it would be simpler and more readable to replace MODULE_PATHNAME with
> $libdir in the sources. Unless somebody can
On Dec 10, 2010, at 12:26 AM, Dimitri Fontaine wrote:
> What if $extension.control exists? Is it a byproduct of the .in file
> from previous `make` run or a user file? What if we have both the .in
> and the make variable because people are confused? Or both the make
> variables and a .control and
Dimitri Fontaine writes:
> Tom Lane writes:
>> Why is it in the makefile at all? If the makefile does need to know it,
>> why don't we have it scrape the number out of the control file? Or even
>> more to the point, since when do we need version numbers in extensions?
> It's in the Makefile so
Tom Lane writes:
> Why is it in the makefile at all? If the makefile does need to know it,
> why don't we have it scrape the number out of the control file? Or even
> more to the point, since when do we need version numbers in extensions?
It's in the Makefile so that you find it in the control
Dimitri Fontaine writes:
> Tom Lane writes:
>> Are there any actual remaining use-cases for that sed step?
> The goal here is to allow extension authors to maintain their version
> number in the Makefile rather than in the Makefile and in the control
> file separately. Having the same version nu
Tom Lane writes:
> Are there any actual remaining use-cases for that sed step?
The goal here is to allow extension authors to maintain their version
number in the Makefile rather than in the Makefile and in the control
file separately. Having the same version number in more than one place
never e
Dimitri Fontaine writes:
> "David E. Wheeler" writes:
>>> What if $extension.control exists? Is it a byproduct of the .in file
>>> from previous `make` run or a user file? What if we have both the .in
>>> and the make variable because people are confused? Or both the make
>>> variables and a .con
"David E. Wheeler" writes:
> On Dec 9, 2010, at 12:34 PM, Dimitri Fontaine wrote:
>> - add support for 'relocatable' boolean property in the control file,
>> as discussed on list
>
> This still isn't ideal, but I think it's a big improvement. Thanks.
Glad you like it :) If you see any way to ma
On Dec 9, 2010, at 12:34 PM, Dimitri Fontaine wrote:
> - add support for 'relocatable' boolean property in the control file,
> as discussed on list
>
> this controls what happens at create extension time, by doing a
> relocation of the extension objects when the extension is relocatable
>
34 matches
Mail list logo
