Re: New variable server_version_num

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-patches(at)postgresql(dot)org
Subject: Re: New variable server_version_num
Date: 2006-08-01 20:25:00
Message-ID: 87d5bkryoz.fsf@wolfe.cbbrowne.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-patches

Quoth david(at)fetter(dot)org (David Fetter):
> 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(at)fetter(dot)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. :)

There's *some* data to be gotten from
select setting from pg_catalog.pg_settings where name = 'server_version';

Seems to me that value isn't without its uses...

cbbrowne(at)dba2:pgsql-HEAD/doc/src/sgml> for port in 5432 5533 5532 5882; do
for> psql -p $port -h localhost -d template1 -c "select '$port',
setting from pg_catalog.pg_settings where name like 'server_version';"
for> done
?column? | setting
----------+---------
5432 | 7.4.13
(1 row)

?column? | setting
----------+---------
5533 | 7.4.10
(1 row)

?column? | setting
----------+---------
5532 | 8.0.5
(1 row)

?column? | setting
----------+----------
5882 | 8.2devel
(1 row)

If I wanted to, it oughtn't be difficult to "string smash" those
settings into something very nearly useful...
--
"cbbrowne","@","gmail.com"
http://linuxfinances.info/info/rdbms.html
">in your opinion which is the best programming tools ?
The human brain and a keyboard." -- Nathan Wagner

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-08-01 20:32:38 Re: Autovacuum help..
Previous Message Nikolay Samokhvalov 2006-08-01 20:07:47 Re: proper use of array datatype

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-08-01 20:26:44 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] 8.2 features?)
Previous Message Tom Lane 2006-08-01 20:15:51 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] 8.2 features?)

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2006-08-01 20:26:44 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] 8.2 features?)
Previous Message Tom Lane 2006-08-01 20:15:51 Re: Values list-of-targetlists patch for comments (was Re: [PATCHES] 8.2 features?)