From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Thomas Hallgren" <thhal(at)mailblocks(dot)com> |
Cc: | "Joe Conway" <mail(at)joeconway(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Module dependency on PostgeSQL version |
Date: | 2004-05-12 12:47:09 |
Message-ID: | 23963.1084366029@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Joe Conway wrote:
>> #if (CATALOG_VERSION_NO <= 200211021)
>> #define PG_VERSION_73_COMPAT
>>
>> Since CATALOG_VERSION_NO doesn't change between major releases, it seems
>> to work pretty well.
That approach also has the nice property that it already works for all
releases back to 7.0, whereas anything we add now would only be useful
starting in 7.5 ...
"Thomas Hallgren" <thhal(at)mailblocks(dot)com> writes:
> 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.
Perhaps not, but I think it would be pretty risky to depend on an #ifdef
to tell you which backend minor version you're running in anyway. Addon
libraries are unlikely to get upgraded at the same times that the
backend does, so it's certainly plausible that you could be running in a
later minor release than you were compiled with. If people copy
executables between machines then the reverse is easily possible too.
The only real version tiedown we have at the moment is to put extension
libraries into a PG-version-specific $libdir, and that is not going to
narrow things more closely than the PG major version in most setups.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2004-05-12 13:46:24 | Re: Subtle pg_dump problem... |
Previous Message | Tom Lane | 2004-05-12 12:35:48 | Re: Configure redux. |