Bruce Momjian 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
Bruce Momjian 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 p
Technically pg_migrator does not need the PG_MODULE_MAGIC version checks
because it doesn't do any data manipulation and it already checks the
new server version to determine if the function calls will resolve.
However, we currently require PG_MODULE_MAGIC for all loaded libraries,
and this adds a
Tom Lane wrote:
No, each major release (8.2, 8.3, etc). There are hardly ever any major
releases where you wouldn't need a new compilation anyway ...
True. I'm all in favor of a magic used this way. It will save me some grief.
Regards,
Thomas Hallgren
---(end of b
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> A module magic patch was added recently and I'm a bit uncertain what the
> implications are
> for the external PL modules. Does it affect them at all?
Yes.
> Will I need to provide separate
> binaries for each bug fix release even though the API's
A module magic patch was added recently and I'm a bit uncertain what the implications are
for the external PL modules. Does it affect them at all? Will I need to provide separate
binaries for each bug fix release even though the API's do not change? Exactly how is the
magic determined?
Regards
