Re: Extensions, patch v16

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, David Fetter <david(at)fetter(dot)org>, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions, patch v16
Date: 2010-12-29 20:23:42
Message-ID: 832.1293654222@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <bruce(at)momjian(dot)us> 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
> the version string into the C code and perhaps a psql variable?

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 file itself (so that we can tell whether we
need to take action to update the extension's catalog entries). I'm not
convinced yet whether there needs to be another version number embedded
in the .so file --- it may well be that the PG major version number
embedded with PG_MODULE_MAGIC is sufficient.

Personally I'd forget the notion of major.minor numbers here; all that
will accomplish is to complicate storage and comparison of the numbers.
We just need a simple integer that gets bumped whenever the extension's
SQL script changes.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2010-12-29 20:31:46 Re: 9.1alpha3 release notes help
Previous Message Kevin Grittner 2010-12-29 20:20:40 Re: SSI SLRU strategy choices