Re: Module dependency on PostgeSQL version

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

In response to

Browse pgsql-hackers by date

  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.