Re: 10.0

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Josh berkus <josh(at)agliodbs(dot)com>, David Fetter <david(at)fetter(dot)org>, Thom Brown <thom(at)linux(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 10.0
Date: 2016-06-14 21:13:52
Message-ID: 63b85eb2-e161-4455-9ba0-3c613844e7ec@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 6/14/16 3:56 PM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
>> On 6/14/16 3:01 PM, Robert Haas wrote:
>>> This seems kind of silly, because anybody who is writing code that
>>> might have to run against an existing version of the database won't be
>>> able to use it. The one thing that absolutely has to be cross-version
>>> is the method of determining which version you're running against.
>
>> We're talking about a function that doesn't currently exist anyway.
>
> Huh? We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM,
> and related APIs. Those most certainly exist now, and trying to supplant
> them seems like a giant waste of time.
>
> On the other hand, parsing fields out of version() mechanically has been
> deprecated for as long as those other APIs have existed (which is since
> 8.0 or so). version() is only meant for human consumption, so I see no
> reason it shouldn't just start returning "10.0", "10.1", etc. If that
> breaks anyone's code, well, they should have switched to one of the
> easier methods years ago.

The original post was:

> IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3

and \df *version* on my HEAD doesn't show any other options.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

  • Re: 10.0 at 2016-06-14 20:56:47 from Tom Lane

Responses

  • Re: 10.0 at 2016-06-14 21:58:44 from Merlin Moncure

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-06-14 21:15:27 Re: 10.0
Previous Message Andreas Seltenreich 2016-06-14 21:01:53 Should pg_export_snapshot() and currtid() be tagged parallel-unsafe?