Skip site navigation (1) Skip section navigation (2)

Re: New variable server_version_num

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Greg Sabino Mullane <greg(at)turnstep(dot)com>,pgsql-patches(at)postgresql(dot)org
Subject: Re: New variable server_version_num
Date: 2006-07-30 06:25:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-hackerspgsql-patches
On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote:
> Greg Sabino Mullane <greg(at)turnstep(dot)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 :)

David Fetter <david(at)fetter(dot)org>
phone: +1 415 235 3778        AIM: dfetter666
                              Skype: davidfetter

Remember to vote!

In response to


pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2006-07-30 08:03:25
Subject: Re: Going for "all green" buildfarm results
Previous:From: Alvaro HerreraDate: 2006-07-30 06:20:05
Subject: Re: Going for "all green" buildfarm results

pgsql-patches by date

Next:From: Tom LaneDate: 2006-07-30 15:27:33
Subject: Re: New variable server_version_num
Previous:From: Bruce MomjianDate: 2006-07-30 02:16:27
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each

pgsql-general by date

Next:From: Ron JohnsonDate: 2006-07-30 07:46:16
Subject: Joining dates/times (was Re: Splitting Timestamps)
Previous:From: Andreas KretschmerDate: 2006-07-30 05:34:25
Subject: Re: create function syntax error

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group