Re: Module dependency on PostgeSQL version - Mailing list pgsql-hackers

From Thomas Hallgren
Subject Re: Module dependency on PostgeSQL version
Date
Msg-id thhal-0im59AdmEClwobrZmWo1v9TR6r5ItVx@mailblocks.com
Whole thread Raw
In response to Module dependency on PostgeSQL version  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: Module dependency on PostgeSQL version  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> This is what I currently have:
>
> #if (CATALOG_VERSION_NO <= 200211021)
> #define PG_VERSION_73_COMPAT
> #elif (CATALOG_VERSION_NO <= 200310211)
> #define PG_VERSION_74_COMPAT
> #else
> #define PG_VERSION_75_COMPAT
> #endif
>
> Since CATALOG_VERSION_NO doesn't change between major releases, it seems
> to work pretty well.
>
> Joe
>
Ok, thanks for the tip. Somewhat cleaner than what I suggested.

Your solution doesn't cover the situations when you have dependencies on
patch versions though, does it? There's no way to distinguish between 7.4.1
and 7.4.2 if the catalog version doesn't change. Such situations will arise.
A module author finds a bug in the backend, reports it, and creates a less
than perfekt work-around in his own code. At some point the bug gets
properly fixed and included in some patch release. Using that release, the
work-around is obsolete.

I had an example when this happened a while back (concerning loss of
MemoryContext between function ivocations). My workaround was really ugly
(using the parent MemoryContext) and could potentially waste a lot of memory
so it was imperative to actually get rid of it as soon as the patch was
released.

regards,

Thomas Hallgren




pgsql-hackers by date:

Previous
From: Shachar Shemesh
Date:
Subject: Re: Probably security hole in postgresql-7.4.1
Next
From: "Thomas Hallgren"
Date:
Subject: Re: Module dependency on PostgeSQL version