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
>>
