Prev: [HACKERS] GUC failure on exception
Next: attoptions
From: Tom Lane on 15 Jan 2010 00:45
Bruce Momjian <bruce(a)momjian.us> writes:
> For example, right now pg_migrator can migrate to 8.4 and 8.5, but there
> is no way to distribute a binary that will migrate to both because you
> need different shared libraries with different PG_MODULE_MAGIC values.

[ yawn... ] By the time 8.5 (9.0?) ships, this will probably not be
true. Quit stressing about it and figure on shipping a pg_migrator
per version.

> I am not sure what to suggest except perhaps that there be some way to
> link in a shared object without the magic block checks.

We are *not* doing that. The potential for error, and costly debug
time, greatly outweighs any possible savings.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dimitri Fontaine on 16 Jan 2010 06:25
Bruce Momjian <bruce(a)momjian.us> writes:
> Another option would be to distribute both 8.4 and 8.5 shared objects,
> but that would require access to two source trees to perform the
> compile, which seems very error-prone.

That's what any extension author and/or packager is faced with. Using
debian, it's easy enough to have more than one postgresql-server-dev-8.X
package at the same time and then use VPATH builds.

I guess the scripts I'm preparing for easing the debian packaging of
extensions should be usable on other Unix systems too, after adapting
some of the paths.

http://lists.alioth.debian.org/pipermail/pkg-postgresql-public/2010-January/000546.html

Regards,
--
dim

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: [HACKERS] GUC failure on exception
Next: attoptions