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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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!

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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!

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Quoth david@fetter.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@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.

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@dba2gsql-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

On Tue, Aug 01, 2006 at 04:25:00PM -0400, Christopher Browne wrote:
> ?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...

It may or may not be difficult, depending on your definition of
'difficult,' but it's very easy and reproducible to get something that
can be cast to integer and compared that way. The existence of
version-number-comparison libraries like version.pm points to the idea
that it is, in fact, difficult to compare versions in general.

Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter

Remember to vote!

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend