Re: [HACKERS] [PATCHES] New variable server_version_num
David Fetter wrote: On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote: Today on IRC David Fetter and some others were discussing version numbers and we realized that although libpq now provides the version of Postgres as a number, this is still a wheel that is being reinvented by apps many times over, as it is not available any other way. Hence, a 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. What's the status on applying this patch? It is still in my mailbox. I am thinking it should be added. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] New variable server_version_num
On Sat, Jul 29, 2006 at 09:14:16PM -0400, Greg Sabino Mullane wrote: Today on IRC David Fetter and some others were discussing version numbers and we realized that although libpq now provides the version of Postgres as a number, this is still a wheel that is being reinvented by apps many times over, as it is not available any other way. Hence, a 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. What's the status on applying this patch? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] New variable server_version_num
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] New variable server_version_num
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] New variable server_version_num
On Sat, Jul 29, 2006 at 09:44:10PM -0400, Tom Lane wrote: Greg Sabino Mullane [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] New variable server_version_num
David Fetter [EMAIL PROTECTED] 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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] New variable server_version_num
On Sun, Jul 30, 2006 at 11:27:33AM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: 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
Re: [HACKERS] [PATCHES] New variable server_version_num
On 7/30/06, David Fetter [EMAIL PROTECTED] 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| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] New variable server_version_num
On Sun, Jul 30, 2006 at 12:17:57PM -0400, Jonah H. Harris wrote: On 7/30/06, David Fetter [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] New variable server_version_num
Greg Sabino Mullane [EMAIL PROTECTED] 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 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
