Re: 10.0

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: 10.0
Дата
Msg-id CAKFQuwZ3b4FJoSN8H_zovuOqDsNrTKaP2-UCveK+gFEO2kRkhw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 10.0  (Mark Dilger <hornschnorter@gmail.com>)
Ответы Re: 10.0  (Mark Dilger <hornschnorter@gmail.com>)
Список pgsql-hackers
On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

> On Jun 20, 2016, at 8:53 AM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
>
> This is not a plea for keeping the three part versioning system.  It's just
> a plea not to have a 2 part versioning system masquerading as a three
> part versioning system, or vice versa.

To clarify my concern, I never want to have to write code like this:

        CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN foo()
                   WHEN pg_version eq '11.2' OR pg_version eq '11.0.2' THEN bar()
                ....
or

        if (0 == strcmp(pg_version_string, "11.1") || 0 == strcmp(pg_version_string, "11.0.1"))
                foo();
        else if (0 == strcmp(pg_version_string, "11.2") || 0 == strcmp(pg_version_string, "11.0.2"))
                bar();

either in sql, perl, c, java, or anywhere else.  As soon as you have two different
formats for the version string, you get into this hell.  Yeah, ok, you may have
a sql level function for this, but I'm thinking about applications somewhat removed
from a direct connection to the database, where you can't be sure which format
you'll be handed.

Now you argue for keeping the middle number on pure compatibility grounds.​..

The correct format is:  110001 and 110002

Which pretty much boils down to "we're keeping the middle number but it will always be zero".

So, I'll suppose you are giving a +1 to keeping the human-readable display 10.0.x - and will let other's interpret your reasons as they will.

David J.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Dilger
Дата:
Сообщение: Re: 10.0
Следующее
От: Tom Lane
Дата:
Сообщение: Re: New design for FK-based join selectivity estimation