From: | "Thomas Hallgren" <thhal(at)mailblocks(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Joe Conway" <mail(at)joeconway(dot)com> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Module dependency on PostgeSQL version |
Date: | 2004-05-12 07:41:56 |
Message-ID: | thhal-0im59AdmEClwobrZmWo1v9TR6r5ItVx@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Shachar Shemesh | 2004-05-12 07:46:00 | Re: Probably security hole in postgresql-7.4.1 |
Previous Message | Simon Riggs | 2004-05-12 07:23:20 | Re: XLog: how to log? |