Thread: Re: [PATCHES] New variable server_version_num
Greg Sabino Mullane <greg@turnstep.com> writes:
> small patch to provide a new variable "server_version_num", which is
> almost the same as "server_version" but uses the handy PG_VERSION_NUM
> which allows apps to do things like if ($version >= 80200) without
> having to parse apart the value of server_version themselves.
This seems pretty useless, as it will be many years before any app that
actually tries to deal with back server versions could rely on the
variable existing.
The correct solution is for client-side libraries to provide the
feature. libpq already does (PQserverVersion()) ... and it works
for any server version from about 6.4 forward ...
regards, tom lane
On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote: > Greg Sabino Mullane <greg@turnstep.com> writes: > > small patch to provide a new variable "server_version_num", which > > is almost the same as "server_version" but uses the handy > > PG_VERSION_NUM which allows apps to do things like if ($version >= > > 80200) without having to parse apart the value of server_version > > themselves. > > This seems pretty useless, as it will be many years before any app > that actually tries to deal with back server versions could rely on > the variable existing. In my case, its non-existence is a guarantee that the server version number isn't high enough :) > The correct solution is for client-side libraries to provide the > feature. Not if the app is written in SQL, as the bootstrap, regression test, etc. code for modules frequently is. > libpq already does (PQserverVersion()) ... and it works for any > server version from about 6.4 forward ... See above for why it's good also to have it surfaced to SQL :) Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
David Fetter <david@fetter.org> writes:
> On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
>> The correct solution is for client-side libraries to provide the
>> feature.
> Not if the app is written in SQL, as the bootstrap, regression test,
> etc. code for modules frequently is.
SQL doesn't really have any conditional ability strong enough to deal
with existence or non-existence of features. What are you hoping to
do, a CASE expression? Both arms of the CASE still have to parse,
so I remain unconvinced that there are real world uses.
regards, tom lane
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote: > >> The correct solution is for client-side libraries to provide the > >> feature. > > > Not if the app is written in SQL, as the bootstrap, regression > > test, etc. code for modules frequently is. > > SQL doesn't really have any conditional ability strong enough to > deal with existence or non-existence of features. What are you > hoping to do, a CASE expression? Both arms of the CASE still have > to parse, so I remain unconvinced that there are real world uses. Failure to parse means the transaction bails out, which is just what I want in my case, as it disallows people attempting to run the programs--they're for DBI-Link--on too early a version of PostgreSQL. As there are some subtleties to the implementation, I need something that quickly returns boolean or fails entirely when it detects same. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On 7/30/06, David Fetter <david@fetter.org> wrote: > Failure to parse means the transaction bails out, which is just what I > want in my case, as it disallows people attempting to run the > programs--they're for DBI-Link--on too early a version of PostgreSQL. > As there are some subtleties to the implementation, I need something > that quickly returns boolean or fails entirely when it detects same. From an application development standpoint, it would be nice to have a strictly numeric version returning function for checking server compatibility. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
On Sun, Jul 30, 2006 at 12:17:57PM -0400, Jonah H. Harris wrote: > On 7/30/06, David Fetter <david@fetter.org> wrote: > >Failure to parse means the transaction bails out, which is just > >what I want in my case, as it disallows people attempting to run > >the programs--they're for DBI-Link--on too early a version of > >PostgreSQL. As there are some subtleties to the implementation, I > >need something that quickly returns boolean or fails entirely when > >it detects same. > > From an application development standpoint, it would be nice to have > a strictly numeric version returning function for checking server > compatibility. It sure would :) Cheers, D (whose boolean function is the output of a numeric comparison between the required server version and the one at hand) -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote: > David Fetter <david@fetter.org> writes: > > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote: > >> The correct solution is for client-side libraries to provide the > >> feature. > > > Not if the app is written in SQL, as the bootstrap, regression test, > > etc. code for modules frequently is. > > SQL doesn't really have any conditional ability strong enough to deal > with existence or non-existence of features. What are you hoping to > do, a CASE expression? Both arms of the CASE still have to parse, > so I remain unconvinced that there are real world uses. There's also plpgsql, which afaik has no way to get the version number (other than slogging though the output of version()). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Tue, Aug 01, 2006 at 12:37:48PM -0500, Jim C. Nasby wrote:
> On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote:
> > David Fetter <david@fetter.org> writes:
> > > On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> > >> The correct solution is for client-side libraries to provide
> > >> the feature.
> >
> > > Not if the app is written in SQL, as the bootstrap, regression
> > > test, etc. code for modules frequently is.
> >
> > SQL doesn't really have any conditional ability strong enough to
> > deal with existence or non-existence of features. What are you
> > hoping to do, a CASE expression? Both arms of the CASE still have
> > to parse, so I remain unconvinced that there are real world uses.
CREATE OR REPLACE FUNCTION version_new_enough(
in_version INTEGER
)
RETURNS BOOLEAN
LANGUAGE sql
AS $$
SELECT
COALESCE(
s.setting::INTEGER, /* Cast setting to integer if it's there */
$1 - 1 /* Otherwise, guarantee a lower number than the input */
) >= $1
FROM
(SELECT 'server_version_num'::text AS name) AS foo
LEFT JOIN
pg_catalog.pg_settings s
ON (foo.name = s.name)
$$;
> There's also plpgsql, which afaik has no way to get the version
> number (other than slogging though the output of version()).
Right. String-mashing is great when you have to do it, but this patch
sets it up so you don't have to. :)
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!