Re: 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 <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!