Re: Extensions, patch v16

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions, patch v16
Date: 2010-12-10 19:38:38
Message-ID: 8F791603-F3F8-42DF-B6DF-66B339A81B43@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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:
>
> EXTVERSION = $(shell dpkg-parsechangelog | awk -F '[:-]' '/^Version:/ { print substr($$2, 2) }')
>
> That comes from a real world example that's yet to be adapted to being
> an extension in 9.1, but still:
>
> https://github.com/dimitri/pgfincore/blob/debian/Makefile

I use that in pgTAP, too (line 23):

https://github.com/theory/pgtap/blob/master/Makefile

But I don't need core to support that. Frankly, if we're not going to generate the control file from Makefile variables, then I'd rather not have any control file Makefile variables at all.

> 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 that the
> module has already been taken care of by the OS-level packaging.

Yeah, this will be needed ASAP.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-12-10 19:42:24 Re: Extensions, patch v16
Previous Message BRUSSER Michael 2010-12-10 19:29:20 Re: initdb failure with Postgres 8.4.4