Re: [HACKERS] 10.0

2016-06-30 Thread Alvaro Herrera
Gavin Flower wrote:

> I hate the rampant inflation associated with numbering schemes like FireFox
> - the numbers of no meaning at all, other than something non-trivial has
> been changed, with no indication at all about how non-trivial!

I thought this horse had already been beaten to death -- apparently not?

It was stated somewhere in these threads that the problem with the
Firefox scheme is that they release new versions every six weeks, so
naturally there is enormous version number inflation.  In our case we
would still release new versions once a year, so by 2026 (ten years from
now) we would be releasing Postgres 19 while Firefox will be in version 133.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-29 Thread Gavin Flower

On 21/06/16 03:53, Mark Dilger wrote:

On Jun 18, 2016, at 5:48 PM, Josh Berkus  wrote:

On 06/16/2016 11:01 PM, Craig Ringer wrote:

I thought about raising this, but I think in the end it's replacing one
confusing and weird versioning scheme for another confusing and weird
versioning scheme.

It does have the advantage that that compare a two-part major like
090401 vs 090402 won't be confused when they compare 100100 and 100200,
since it'll be 11 and 12. So it's more backward-compatible. But
ugly.


Realistically, though, we're more likely to end up with 10.0.1 than
10.1.  I don't think we're anywhere near plumbing the depths of the
stuff which will break because folks are parsing our version numbers
with regexes.  In more major software, this will break nagios
check_postgres.

Having a 3 part versioning scheme where the middle portion is always
zero makes the least sense to me of any of the proposals.  If we're going
to have the pain and hurting of moving to a 2 part versioning scheme,
and breaking nagios and what not, then lets just get on with it.  If we're
going to keep all three parts, can we please use my proposal earlier in
this thread where A.B.C are allocated for:

C++:  bug fixes only
B++:  new features added, but still backward compatible with prior version
A++:  new features added, not backward compatible, pg_upgrade required

If every new feature release ends up requiring pg_upgrade, then B will
always be zero, which is no worse than your proposal.  But at least users can
refer to part B to learn something useful, namely whether they will need to
run pg_upgrade as part of upgrading their existing cluster.

This has the advantage that new minor features, like adding a new guc, can
be released sooner than the next major release, but does not have to be
released in disguise as if it were a bug fix.

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.

mark



I agree with this!

I hate the rampant inflation associated with numbering schemes like 
FireFox - the numbers of no meaning at all, other than something 
non-trivial has been changed, with no indication at all about how 
non-trivial!




Cheers,
Gavin



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-21 Thread José Luis Tallón

On 06/20/2016 10:14 PM, Robert Haas wrote:

On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
 wrote:

10.x is the desired output.

10.x is the output that some people desire.


(explicitly skipped up-thread to add this -- please forgive my jumping in)

Since we are still (as a community) debating this, I felt the need to 
add yet another possibility ...

(/me dons some asbestos underwear)

next version:
100100 [server_version] will be  (gasp!)  10g R1 (for marketing people) 
or simply 10.1.0 for the rest of the world.

Next update would be 1001001, a.k.a. 10g R1 u1

i.e. we would skip 10.0 alltogether, preserving everybody's sanity 
in the process.



IMV,  10g R1 uX should plainly be a different *major* release than 10g 
R2 uY

and hence requiring a proper "migration" (i.e. pg_upgrade)
...or at least that's what several multi-billion software companies 
have taught most everybody to believe :$




A significant number of
people, including me, would prefer to stick with the current
three-part versioning scheme, possibly with some change to the
algorithm for bumping the first digit (e.g. every 5 years like
clockwork).
That's another story  Either 5 (for historical reasons) or 10 year 
(sounds good)
 ... or whenever it makes sense! (such as when a multi-modal, hybrid 
row+column, vectored, MPP, super-duper-distributed, automagically 
self-scaling or the like release is ready)



Thanks,

/ J.L.



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-21 Thread Cédric Villemain
On 20/06/2016 22:41, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Robert Haas  writes:
>>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>>>  wrote:
 10.x is the desired output.
>>
>>> 10.x is the output that some people desire.  A significant number of
>>> people, including me, would prefer to stick with the current
>>> three-part versioning scheme, possibly with some change to the
>>> algorithm for bumping the first digit (e.g. every 5 years like
>>> clockwork).
>>
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.
> 
> I voted for this approach initially too, and I think it has merit --
> notably, that it would stop this discussion.  It was said that moving
> to two-part numbers would stop all discussion, but it seems to have had
> exactly the opposite effect.

If voting is still possible, then I agree: no changes please!
It won't make things easier to have a 10g or a 10.8 to explain, instead
of a 10.0.8... and I'm not sure it'll make things easier to not have the
chance to bump the 2 major parts if it happened to be interesting in the
future like it was for 7.4->8 and 8.4->9 (9 is «new», it's the first
time we go over .4 to bump first digit, but it's also the first time we
have found a way to shorten release cycle)

-- 
-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Bruce Momjian
On Mon, Jun 20, 2016 at 05:11:17PM -0400, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane  wrote:
> > No, the argument for it was that we'd no longer have to have the annual
> > discussions about "is it 10.0 yet?".
> 
> WHAT annual argument?  Did anyone even argue that any 9.x release
> prior to 9.6 deserved to be called 10.0?  Maybe somebody suggested
> that for 9.2 and it generated, like, four emails?  I certainly don't
> remember any discussion that remotely approached the amount of time
> we've spent litigating both the version number and the version
> numbering scheme in the last few months.

I do think Robert is 100% accurate on this.  Personally, I have never
understood the reduce arguments reason, and the jump to 8.0 and 9.0 were
done in a positive way that I think provided value to our community.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Bruce Momjian
On Mon, May 16, 2016 at 10:16:48AM -0400, Tom Lane wrote:
> Peter Eisentraut  writes:
> > On 5/16/16 9:53 AM, Greg Stark wrote:
> >> I thought the idea was that Berkeley tossed an source tree over the
> >> wall with no version number and then the first five releases were
> >> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
> >> Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
> >> major release counting those as the first five releases.
> 
> > The last release out of Berkeley was 4.2.
> 
> Correct --- I have a copy of that tarball.
> 
> > Then Postgres95 was "5", and then PostgreSQL started at 6.
> 
> I wasn't actually around at the time, but our commit history starts
> with this:
> 
> Author: Marc G. Fournier 
> Branch: master Release: REL6_1 [d31084e9d] 1996-07-09 06:22:35 +
> 
> Postgres95 1.01 Distribution - Virgin Sources
> 
> The first mention of 6.anything is here:
> 
> Author: Bruce Momjian 
> Branch: master Release: REL6_1 [a2b7f6297] 1996-12-28 02:01:58 +
> 
> Updated changes for 6.0.
> 
> I see no references in the commit history to 5.anything, but there
> are some references like this:

The sole reason we jumped from Postgres 1.09 to 6.0 was that in Postgres
1.0.X, $PGDATA/PG_VERSION contained '5', meaning when Berkeley went from
University Postgres 4.2 to Postgres95 1.0, they didn't reset PG_VERSION.

We really had no way of going to Postgres 2.0 unless we were prepared to
have data/PG_VERSION never match the major version number.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Robert Haas
On Mon, Jun 20, 2016 at 5:36 PM, David G. Johnston
 wrote:
>> Yeah, no kidding.  We had a perfectly good consensus to keep this at
>> 9.6 on pgsql-advocacy, and then later we had a revised consensus to
>> retitle it to 10.0,
>
> If -advocacy had changed their mind before beta1 was tagged this may have
> played out a bit differently...maybe.  In any case 9.6 was a foregone
> conclusion given -advocacy's timeline and because of its independence from
> -hackers (Tom, the tagger, specifically).

One thing to keep in mind is that I did not realize there was any
urgency to make the decision before beta1, because Tom had previous
made reference to renumbering this version to 10.0 *over the summer*
depending on how awesome we then thought parallel query was.  I
assumed that he would not have made this comment if he had an
objection to renumbering the release after beta1.  Surely he didn't
think we were going to do beta1 in the fall.  It was only after beta1
had been released that anyone said post-beta1 was too late.  Had that
been brought up earlier, the discussion might have gone differently,
too.

Also, it is not the case that because Tom applies the tag, he also
gets veto power over the version numbering scheme.  That's not how
decision-making in this community works.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 5:08 PM, Robert Haas  wrote:

> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake 
> wrote:
> > Or we could adopt the very reasonable and practical policy of:
> >
> > The current versioning scheme isn't broke, so we aren't going to fix it.
>
> Yeah, no kidding.  We had a perfectly good consensus to keep this at
> 9.6 on pgsql-advocacy, and then later we had a revised consensus to
> retitle it to 10.0,


​If -advocacy had changed their mind before beta1 was tagged this may have
played out a bit differently...maybe.​  In any case 9.6 was a foregone
conclusion given -advocacy's timeline and because of its independence from
-hackers (Tom, the tagger, specifically).

but as soon as the discussion came over to
> pgsql-hackers nothing would do but that we relitigate the whole thing
> ignoring the previous discussion because it wasn't on pgsql-hackers.
> Why -hackers is the right place to decide on the marketing version
> number rather than -advocacy went unexplained, of course.


​I had the same thought.  Yet no one even tried to move the discussion back
there.  And at this point PGCon was so close that I personally figured it
would be discussed.  It was, and an announcement was made that a decision
was reached.  No one voiced an objection​ so those not at PGCon (or at I)
figured for better or worse we're going to version 10 (expected) and to
address the expressed desire reduce the public confusion surrounding our
major-major-minor version scheme we would instead switch to a more
traditional major-minor scheme (acceptable).

  Now we have
> a new consensus, at least the third if not the fourth or fifth, about
> what to do on this topic, and since Tom likes this outcome better he'd
> like to stop discussion right here.


​This portion of the thread was mostly a technical concern - how do we
display the version in human-readable and machine-readable formats.  I'd
agree with your earlier idea that if you really want to open up the
decision between 10.n.x and 10.x ​start a new thread on -advocacy.  Tally
up those at PGCon as a starting point and lets other toss in their lot from
there.  At this point I'm only seeing rehashing of the same arguments.  Let
other people make their, informed or otherwise, opinions known if you feel
that the group at PGCon is not a fair sampling.


> A two-part version numbering
> scheme may or may not be for the best, but the idea that we're making
> that decision in any principled way, or that the consensus on this new
> system is any more valid than any of the previous consensus, doesn't
> ring true to me.  The idea that this discussion is not fixing any real
> problem, though -- that rings true.
>
>
You've hijack the meaning of "this here.  Most of "this" thread ended up
explaining the difference between "version()" and
current_setting('server_version_num").  That needs to be addressed unless
we revert back to status-quo.  That isn't this thread, though.  This thread
assumes we are going to 10.0 and semantically losing the middle digit.

I'd find it odd to argue against 10.0 on the basis that we'd be displaying
10.0.x in the output of version().  That seems like such a inconsequential
detail in the larger scheme of things.  Either you accept 10.0 and we pick
a human readable output or you don't and the decision doesn't come into
play.  I'm happy with how things are (+0.5 for we should output 10.0.x for
version()) so I'm stopping here.

David J.
​


Re: [HACKERS] 10.0

2016-06-20 Thread Joshua D. Drake

On 06/20/2016 02:14 PM, Merlin Moncure wrote:

On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas  wrote:

On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake  wrote:

Or we could adopt the very reasonable and practical policy of:

The current versioning scheme isn't broke, so we aren't going to fix it.


The idea that this discussion is not fixing any real
problem, though -- that rings true.


sure -- it's my fault for starting the conversation back up.  I was
wondering about supporting older version checks, but only because I
was unaware of the 'machine' variant of the version check
(server_version_num), which properly supports numerical ordering for
historical versions.  If there's anything to do here, maybe we ought
to document that server_version_num should be used for checking
version a little more strongly.  Judging by google searching, this is
as not widely known as it should be.


I certainly had no idea it even existed until you displayed the query. I 
have always used version() but then, I am not a -hacker.


Sincerely,

JD



merlin




--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Merlin Moncure
On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas  wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake  
> wrote:
>> Or we could adopt the very reasonable and practical policy of:
>>
>> The current versioning scheme isn't broke, so we aren't going to fix it.
>
> The idea that this discussion is not fixing any real
> problem, though -- that rings true.

sure -- it's my fault for starting the conversation back up.  I was
wondering about supporting older version checks, but only because I
was unaware of the 'machine' variant of the version check
(server_version_num), which properly supports numerical ordering for
historical versions.  If there's anything to do here, maybe we ought
to document that server_version_num should be used for checking
version a little more strongly.  Judging by google searching, this is
as not widely known as it should be.

merlin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Robert Haas
On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane  wrote:
> No, the argument for it was that we'd no longer have to have the annual
> discussions about "is it 10.0 yet?".

WHAT annual argument?  Did anyone even argue that any 9.x release
prior to 9.6 deserved to be called 10.0?  Maybe somebody suggested
that for 9.2 and it generated, like, four emails?  I certainly don't
remember any discussion that remotely approached the amount of time
we've spent litigating both the version number and the version
numbering scheme in the last few months.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Robert Haas
On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake  wrote:
> Or we could adopt the very reasonable and practical policy of:
>
> The current versioning scheme isn't broke, so we aren't going to fix it.

Yeah, no kidding.  We had a perfectly good consensus to keep this at
9.6 on pgsql-advocacy, and then later we had a revised consensus to
retitle it to 10.0, but as soon as the discussion came over to
pgsql-hackers nothing would do but that we relitigate the whole thing
ignoring the previous discussion because it wasn't on pgsql-hackers.
Why -hackers is the right place to decide on the marketing version
number rather than -advocacy went unexplained, of course.  Now we have
a new consensus, at least the third if not the fourth or fifth, about
what to do on this topic, and since Tom likes this outcome better he'd
like to stop discussion right here.  A two-part version numbering
scheme may or may not be for the best, but the idea that we're making
that decision in any principled way, or that the consensus on this new
system is any more valid than any of the previous consensus, doesn't
ring true to me.  The idea that this discussion is not fixing any real
problem, though -- that rings true.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Tom Lane
Alvaro Herrera  writes:
> Tom Lane wrote:
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.

> I voted for this approach initially too, and I think it has merit --
> notably, that it would stop this discussion.  It was said that moving
> to two-part numbers would stop all discussion, but it seems to have had
> exactly the opposite effect.

No, the argument for it was that we'd no longer have to have the annual
discussions about "is it 10.0 yet?".  There was no claim that getting
there would be uncontroversial, only that things would be quieter once
we did get there.

Considering that same long-term viewpoint, I'm not very happy about the
idea of "let's reserve the middle digit for compatible feature backports",
because the minute we set up a numbering system like that, everybody and
his brother will be arguing for making a branch on which to backport their
favorite more-or-less-compatible new feature.  You as well as others
pointed out that we don't have the manpower to actually support any such
thing ... so let's not open the door to it.

If we do arrive at a consensus that going to simply "10.0, 10.1, etc"
would be too much change, then I'd be in favor of adopting the
every-ten-year rule instead, in hopes that we can at least shut down
future "is it 10.0 yet" threads more quickly.  But that really does
nothing at all to fix the confusion so often shown by outsiders about
the significance of our version numbers.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Robert Haas
On Mon, Jun 20, 2016 at 4:20 PM, Tom Lane  wrote:
> Robert Haas  writes:
>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>>  wrote:
>>> 10.x is the desired output.
>
>> 10.x is the output that some people desire.  A significant number of
>> people, including me, would prefer to stick with the current
>> three-part versioning scheme, possibly with some change to the
>> algorithm for bumping the first digit (e.g. every 5 years like
>> clockwork).
>
> If we were going to do it like that, I would argue for "every ten years
> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
> Robert, you already made your case for that approach and nobody else
> cared for it.  Either there's a meaningful difference between the first
> and second parts of the number, or there is not.  If there is not, why
> have separate parts?  It can only cause confusion ... as this whole
> thread, and its many many predecessors, amply illustrate.

That's not how I remember it.  At the Ottawa developer meeting, there
were more votes for changing to a two-part versioning scheme than
there were for retaining a three-part versioning scheme, but my
recollection not overwhelmingly so.  I'm pretty sure it was less than
a 2/3 majority in favor of changing.

Furthermore, essentially everyone in the room, including people who
wanted to stick with a three-part scheme, was in favor of the next
version's first component being 10.  I do not recall there being a
strong consensus among the people who wanted the next version to be
10.0.0 on how to decide when to go to 11.0.0, though.  Various
proposals were offered and most of them got no more than one vote.

But saying that nobody other than me thought we should stick with a
three-part scheme is revisionist history.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Joshua D. Drake

On 06/20/2016 01:41 PM, Alvaro Herrera wrote:

Tom Lane wrote:

Robert Haas  writes:

On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
 wrote:



If we were going to do it like that, I would argue for "every ten years
like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
Robert, you already made your case for that approach and nobody else
cared for it.


I voted for this approach initially too, and I think it has merit --
notably, that it would stop this discussion.  It was said that moving
to two-part numbers would stop all discussion, but it seems to have had
exactly the opposite effect.



Or we could adopt the very reasonable and practical policy of:

The current versioning scheme isn't broke, so we aren't going to fix it.

Put that in the FAQ and wave at it like we do with hints ala Oracle.

It is obvious from this thread alone that there is really no consensus.

Sincerely,

JD

--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Alvaro Herrera
Tom Lane wrote:
> Robert Haas  writes:
> > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> >  wrote:
> >> 10.x is the desired output.
> 
> > 10.x is the output that some people desire.  A significant number of
> > people, including me, would prefer to stick with the current
> > three-part versioning scheme, possibly with some change to the
> > algorithm for bumping the first digit (e.g. every 5 years like
> > clockwork).
> 
> If we were going to do it like that, I would argue for "every ten years
> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
> Robert, you already made your case for that approach and nobody else
> cared for it.

I voted for this approach initially too, and I think it has merit --
notably, that it would stop this discussion.  It was said that moving
to two-part numbers would stop all discussion, but it seems to have had
exactly the opposite effect.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 4:14 PM, Robert Haas  wrote:

> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>  wrote:
> > 10.x is the desired output.
>
> 10.x is the output that some people desire.  A significant number of
> people, including me, would prefer to stick with the current
> three-part versioning scheme, possibly with some change to the
> algorithm for bumping the first digit (e.g. every 5 years like
> clockwork).
>
> ​
​I was speaking for the project/community as a distinct entity and not
about any individual contributor.​  I'm acting as if we're past the point
of individual opinions and votes on the decision to go to a two-part
versioning scheme.

We will still welcome any major revelations that may have gone unconsidered
during the decision making but I find that to be unlikely.

David J.


Re: [HACKERS] 10.0

2016-06-20 Thread Tom Lane
Robert Haas  writes:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>  wrote:
>> 10.x is the desired output.

> 10.x is the output that some people desire.  A significant number of
> people, including me, would prefer to stick with the current
> three-part versioning scheme, possibly with some change to the
> algorithm for bumping the first digit (e.g. every 5 years like
> clockwork).

If we were going to do it like that, I would argue for "every ten years
like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
Robert, you already made your case for that approach and nobody else
cared for it.  Either there's a meaningful difference between the first
and second parts of the number, or there is not.  If there is not, why
have separate parts?  It can only cause confusion ... as this whole
thread, and its many many predecessors, amply illustrate.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Robert Haas
On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
 wrote:
> 10.x is the desired output.

10.x is the output that some people desire.  A significant number of
people, including me, would prefer to stick with the current
three-part versioning scheme, possibly with some change to the
algorithm for bumping the first digit (e.g. every 5 years like
clockwork).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 20, 2016, at 1:00 PM, David G. Johnston  
> wrote:
> 
> On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger  wrote:
> 
> > Do you have a problem with the human form and machine forms of the version 
> > number being different in this respect?  I don't - for me the decision of a 
> > choice for the human form is not influenced by the fact the machine form 
> > has 6 digits (with leading zeros which the human form elides...).
> 
> I don't have a problem with it if humans always use a two part number.  I 
> don't read
> the number 14 as being three parts, nor as being two parts, so it doesn't 
> matter.
> What got me to respond this morning was Josh's comment:
> 
> "Realistically, though, we're more likely to end up with 10.0.1 than 10.1."
> 
> He didn't say "11 than 10.1", he said "10.0.1 than 10.1", which showed 
> that we
> already have a confusion waiting to happen.
> 
> Now, you can try to avoid the confusion by saying that we'll always use all 
> three
> digits of the number rather than just two, or always use two digits rather 
> than three.
> But how do you enforce that? 
> 
> ​You do realize he was referring to machine generated output here?  

No I don't, nor will anyone who finds that via a google search.  That's my 
point.
You core hackers feel perfectly comfortable with that because you understand
what you are talking about.  Hardly anybody else will.

As you suggest, that's my $0.02, and I'm moving on.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger 
wrote:

>
> > Do you have a problem with the human form and machine forms of the
> version number being different in this respect?  I don't - for me the
> decision of a choice for the human form is not influenced by the fact the
> machine form has 6 digits (with leading zeros which the human form
> elides...).
>
> I don't have a problem with it if humans always use a two part number.  I
> don't read
> the number 14 as being three parts, nor as being two parts, so it
> doesn't matter.
> What got me to respond this morning was Josh's comment:
>
> "Realistically, though, we're more likely to end up with 10.0.1 than 10.1."
>
> He didn't say "11 than 10.1", he said "10.0.1 than 10.1", which showed
> that we
> already have a confusion waiting to happen.
>
> Now, you can try to avoid the confusion by saying that we'll always use
> all three
> digits of the number rather than just two, or always use two digits rather
> than three.
> But how do you enforce that?


​You do realize he was referring to machine generated output here?  That
means unless we get careless we have full control over what is output.​
 Enforcement is easy.

If in some sense the middle number exists, but is
> always zero, then some people will mention it and some won't, with the
> result that
> 10.0.x and 10.x will be used by different people at different times to
> refer to the same
> release.
>

​Back to human generated output again...
​


>
> The problem that Tom and others mentioned upthread (rather a while ago) is
> that
> up until now, we've had three digits in the version numbers, but the first
> two numbers
> really just mean one thing, "major", and the last number means "minor".
> IIUC, he
> wanted to stop using two separate digits where clearly just one would
> suffice.  Hence
> the proposal to go to things like 10.0, 10.1.  But others chimed in saying
> that we need
> to keep it three parts for compatibility reasons, so how about we just
> have the middle
> number always be zero.  My response to that is what I've just said.  You
> can't do that
> without creating ambiguity in future version numbers, because of how
> people use
> language.  If you want to avoid the ambiguity and confusion going forward,
> all the
> numbers in the scheme must have meaning and not be mere placeholders.  I
> gave a
> suggestion about what the middle number *could* mean, which I don't deny
> is what
> I'd like best, but it's just a suggestion to avoid the confusion inherent
> in people eliding
> the middle number sometimes but not other times.
>
>
Given everything else you wrote I find it hard to believe you actually,
deep down, think that
​"definitional ​
meaning
​"​
is sufficient here.  The reason informed people say "9.2.x" and "9.3.x" is
that those are in fact t
​w​
o different things where the middle number changes every year.  If we go
right from: 10.0.7 to 11.0.0 there will be no added value in distinguishing
between 10.0.x
​and ​
10.x and so people will no
​t​
do it - and
​ and you said​
there is no way to force them.
​​  That the middle number could, in well defined circumstances, change is
immaterial when it will not do so in practice.

So, we can ensure the machine output is consistent.  Th
​at​
is easy.​
​  The only question here is whether we make the machine human-readable
output better conform to expected human-generate usage (i.e., 10.x) or do
we keep the machine generated human-readable output compatible with the
existing format so that machine processing of the string is unaffected.​

The only way to address your concern is to continue with the status-quo.
Make 10.1.x and 10.2.x and so people cannot meaningfully drop the second
digit.
​  Since it has been accepted that the status quo has its own problems -
namely that the less informed population are already treating our version
number as if it is 9.x (instead of 9.5.x)​ that change to better conform to
societal expectations is desirable.

​If you're going to vote for status-quo I'd say add your $0.02 and move on;
I don't think that is still on the table (unless some real bad reality
smacks us in the face.  The human generated dynamic is thus a foregone
conclusion - the majority are going to call and write our next release​ as
10.x.  The machine readable output will be 10.  The human readable
output seems to be up for a vote.  10.0.x or 10.x

10.x is the desired output.

Having a list of actual problems likely to face our users if we do this
would be helpful.

Identifying exactly where this human-readable output string appears would
be helpful.  Obviously the "version()" command but where else?

I do think Josh has the right of it, though.  Humans seeing 10.0.4 in the
version() output will easily adapt once they understand why we left it that
way.  Machines cannot adapt as readily.  The fact that we advertise 10.4
while our version number is 10.0.4 in one small corner of out system is a
minor irritant 

Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 3:07 PM, Gražvydas Valeika 
wrote:

> Hi,
>
> I recently bumped into http://semver.org/
>
> It can be interesting to participants of this discussion.
>
> Especially motivation for minor version (middle number).
>
>
​While we appreciate the comment this is third (maybe forth) time this has
come up during this discussion - the last being 20 emails and 3 days ago.
In short, we don't and never will be semver compliant so if anything its
numbering protocol is something to avoid, not embrace.

David J.
​


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 20, 2016, at 11:30 AM, David G. Johnston  
> wrote:
> 
> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger  wrote:
> 
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake  
> > wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I don't quite
> >>> understand what it is.
> >>
> >> I do, indeed, and here it is:
> >>
> >> When considering whether to *back port* a change, we typically do so
> >> on the basis that bug fixes are back ported, features are not.  In my
> >> proposed versioning scheme, you could back port any feature that is
> >> compatible with the old version, and bump the middle number to alert
> >> users that you've not just back ported a bug fix, but a feature.  Any new
> >> features that are not compatible don't get back ported.
> >>
> >> If you fix a bug on master during development, you can back port that
> >> as well.  But instead of bumping the middle number, you bump the last
> >> number.
> >>
> >> Somebody running a version that is three major versions back could
> >> still get the advantage of new features, so long as those new features
> >> are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
> >> as it is to run rpm -U.  You get downtime either way, but the elapsed
> >> time of that downtime is orders of magnitude different.
> >>
> >> Someone else running that same version from three major versions ago
> >> can take a more conservative policy, and only upgrade bug fixes, and
> >> forego the back ported features.
> >>
> >> You still have one major version release per year.  At that time, you can
> >> also release back-port versions of prior major versions.
> >
> > OFFLIST:
> >
> > You are fighting a losing if noble battle.
> 
> I think all my emails on this subject have been seriously misunderstood.
> Perhaps the problem is that I don't understand some critical issue.  Can
> you please help me understand this part:
> 
> It seems like people want releases, starting with 10.0, to be named things
> like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs
> like nagios refer to them as 10.0.0, 10.0.1, 10.0.2
> 
> Is that right?
> 
> That's the part that really annoys me, and I keep trying to argue for not 
> doing
> that, and people keep replying to other parts of my messages rather than
> replying to the core part of what I am saying.
> 
> Why would any sensible person want a release to sometimes be called
> "10.4", but the exact same release sometimes referred to as "10.0.4"?
> This is just going to confuse average software users, as they would never
> expect that 10.4 and 10.0.4 are the same thing.
> 
> Have I misunderstood what is being proposed?
> 
> ​The software is only ever going to report 10.0.4 OR 10.4.  The area of 
> concern is that people are going to get annoyed at saying: "that was fixed in 
> 10.0.4​" and so mailing lists and other forums where people write the numbers 
> instead of a computer are going to be littered with: "that was fixed in 10.4".
> 
> So now human speak and machine speak are disjointed.
>  
> ​The machine form output for that release is going to be 14 regardless of 
> the decision to make the human form 10.4 or 10.0.4
> 
> Do you have a problem with the human form and machine forms of the version 
> number being different in this respect?  I don't - for me the decision of a 
> choice for the human form is not influenced by the fact the machine form has 
> 6 digits (with leading zeros which the human form elides...).

I don't have a problem with it if humans always use a two part number.  I don't 
read
the number 14 as being three parts, nor as being two parts, so it doesn't 
matter.
What got me to respond this morning was Josh's comment:

"Realistically, though, we're more likely to end up with 10.0.1 than 10.1."

He didn't say "11 than 10.1", he said "10.0.1 than 10.1", which showed that 
we
already have a confusion waiting to happen.

Now, you can try to avoid the confusion by saying that we'll always use all 
three
digits of the number rather than just two, or always use two digits rather than 
three.
But how do you enforce that?  If in some sense the middle number exists, but is
always zero, then some people will mention it and some won't, with the result 
that
10.0.x and 10.x will be used by different people at different times to refer to 
the same
release.

The problem that Tom and others mentioned upthread (rather a while ago) is that
up until now, we've had three digits in the version numbers, but the first two 
numbers
really just mean one thing, "major", and the last number means "minor".  IIUC, 
he
wanted to stop using two separate digits where clearly just one would suffice.  
Hence
the proposal to go to things like 10.0, 10.1.  But others chimed in saying that 
we need
to keep it three parts for compatibility reasons, so how about we just have 

Re: [HACKERS] 10.0

2016-06-20 Thread Gražvydas Valeika
Hi,

I recently bumped into http://semver.org/

It can be interesting to participants of this discussion.

Especially motivation for minor version (middle number).


Best,

Grazvydas


On Mon, Jun 20, 2016 at 9:30 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:

> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger 
> wrote:
>
>>
>> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake 
>> wrote:
>> >
>> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
>> >
>> >>> Now maybe you have some other idea in mind, but I don't quite
>> >>> understand what it is.
>> >>
>> >> I do, indeed, and here it is:
>> >>
>> >> When considering whether to *back port* a change, we typically do so
>> >> on the basis that bug fixes are back ported, features are not.  In my
>> >> proposed versioning scheme, you could back port any feature that is
>> >> compatible with the old version, and bump the middle number to alert
>> >> users that you've not just back ported a bug fix, but a feature.  Any
>> new
>> >> features that are not compatible don't get back ported.
>> >>
>> >> If you fix a bug on master during development, you can back port that
>> >> as well.  But instead of bumping the middle number, you bump the last
>> >> number.
>> >>
>> >> Somebody running a version that is three major versions back could
>> >> still get the advantage of new features, so long as those new features
>> >> are not incompatible.  It's frequently not nearly so easy to run
>> pg_upgrade
>> >> as it is to run rpm -U.  You get downtime either way, but the elapsed
>> >> time of that downtime is orders of magnitude different.
>> >>
>> >> Someone else running that same version from three major versions ago
>> >> can take a more conservative policy, and only upgrade bug fixes, and
>> >> forego the back ported features.
>> >>
>> >> You still have one major version release per year.  At that time, you
>> can
>> >> also release back-port versions of prior major versions.
>> >
>> > OFFLIST:
>> >
>> > You are fighting a losing if noble battle.
>>
>> I think all my emails on this subject have been seriously misunderstood.
>> Perhaps the problem is that I don't understand some critical issue.  Can
>> you please help me understand this part:
>>
>> It seems like people want releases, starting with 10.0, to be named things
>> like 10.0, 10.1, 10.2,..., but for the purposes of communicating with
>> programs
>> like nagios refer to them as 10.0.0, 10.0.1, 10.0.2
>>
>> Is that right?
>>
>> That's the part that really annoys me, and I keep trying to argue for not
>> doing
>> that, and people keep replying to other parts of my messages rather than
>> replying to the core part of what I am saying.
>>
>> Why would any sensible person want a release to sometimes be called
>> "10.4", but the exact same release sometimes referred to as "10.0.4"?
>> This is just going to confuse average software users, as they would never
>> expect that 10.4 and 10.0.4 are the same thing.
>>
>> Have I misunderstood what is being proposed?
>>
>
> ​The software is only ever going to report 10.0.4 OR 10.4.  The area of
> concern is that people are going to get annoyed at saying: "that was fixed
> in 10.0.4​" and so mailing lists and other forums where people write the
> numbers instead of a computer are going to be littered with: "that was
> fixed in 10.4".
>
> So now human speak and machine speak are disjointed.
>
> ​The machine form output for that release is going to be 14 regardless
> of the decision to make the human form 10.4 or 10.0.4
>
> Do you have a problem with the human form and machine forms of the version
> number being different in this respect?  I don't - for me the decision of a
> choice for the human form is not influenced by the fact the machine form
> has 6 digits (with leading zeros which the human form elides...).
>
> This thread started with complaint that people are parsing our human form
> output instead of the machine form.  The OP later admitted that he didn't
> realize that a machine form was so readily available.  That is worry-some,
> since I doubt that is an isolated incident,​ and leads to the discussion of
> what form the human intended version should take.
>
> David J.
>
>


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger 
wrote:

>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake 
> wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I don't quite
> >>> understand what it is.
> >>
> >> I do, indeed, and here it is:
> >>
> >> When considering whether to *back port* a change, we typically do so
> >> on the basis that bug fixes are back ported, features are not.  In my
> >> proposed versioning scheme, you could back port any feature that is
> >> compatible with the old version, and bump the middle number to alert
> >> users that you've not just back ported a bug fix, but a feature.  Any
> new
> >> features that are not compatible don't get back ported.
> >>
> >> If you fix a bug on master during development, you can back port that
> >> as well.  But instead of bumping the middle number, you bump the last
> >> number.
> >>
> >> Somebody running a version that is three major versions back could
> >> still get the advantage of new features, so long as those new features
> >> are not incompatible.  It's frequently not nearly so easy to run
> pg_upgrade
> >> as it is to run rpm -U.  You get downtime either way, but the elapsed
> >> time of that downtime is orders of magnitude different.
> >>
> >> Someone else running that same version from three major versions ago
> >> can take a more conservative policy, and only upgrade bug fixes, and
> >> forego the back ported features.
> >>
> >> You still have one major version release per year.  At that time, you
> can
> >> also release back-port versions of prior major versions.
> >
> > OFFLIST:
> >
> > You are fighting a losing if noble battle.
>
> I think all my emails on this subject have been seriously misunderstood.
> Perhaps the problem is that I don't understand some critical issue.  Can
> you please help me understand this part:
>
> It seems like people want releases, starting with 10.0, to be named things
> like 10.0, 10.1, 10.2,..., but for the purposes of communicating with
> programs
> like nagios refer to them as 10.0.0, 10.0.1, 10.0.2
>
> Is that right?
>
> That's the part that really annoys me, and I keep trying to argue for not
> doing
> that, and people keep replying to other parts of my messages rather than
> replying to the core part of what I am saying.
>
> Why would any sensible person want a release to sometimes be called
> "10.4", but the exact same release sometimes referred to as "10.0.4"?
> This is just going to confuse average software users, as they would never
> expect that 10.4 and 10.0.4 are the same thing.
>
> Have I misunderstood what is being proposed?
>

​The software is only ever going to report 10.0.4 OR 10.4.  The area of
concern is that people are going to get annoyed at saying: "that was fixed
in 10.0.4​" and so mailing lists and other forums where people write the
numbers instead of a computer are going to be littered with: "that was
fixed in 10.4".

So now human speak and machine speak are disjointed.

​The machine form output for that release is going to be 14 regardless
of the decision to make the human form 10.4 or 10.0.4

Do you have a problem with the human form and machine forms of the version
number being different in this respect?  I don't - for me the decision of a
choice for the human form is not influenced by the fact the machine form
has 6 digits (with leading zeros which the human form elides...).

This thread started with complaint that people are parsing our human form
output instead of the machine form.  The OP later admitted that he didn't
realize that a machine form was so readily available.  That is worry-some,
since I doubt that is an isolated incident,​ and leads to the discussion of
what form the human intended version should take.

David J.


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 1:48 PM, Mark Dilger 
wrote:

>
> > On Jun 20, 2016, at 9:38 AM, David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> >
> > On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger 
> wrote:
> >
> > > On Jun 20, 2016, at 8:53 AM, Mark Dilger 
> 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.​..
>
> I am not arguing for that.  I'm arguing against having two different
> versions of the
> same thing.  If you go with a two part versioning scheme that is sometimes
> written as a
> three part versioning scheme, you make every bit of code that deals with
> it from now on
> have to deal with both possible versions in order to be robust.
>
> My preference is to have a three part versioning scheme where all three
> parts have
> different purposes.  But since the community seems to have no interest in
> that, and
> have largely (if not universally) rejected that idea, I'm falling back to
> merely arguing
> that if we're going to have a two part versioning system, we should do
> that everywhere,
> and if we can't do that everywhere, then we should do that nowhere.
>
> You appear to be arguing that we should have a versioning scheme that is
> sometimes
> two parts, and sometimes three parts, but when three parts, always make
> the middle
> number zero.  The part of that which bothers me most is not the "always
> zero" part.   It's
> the "sometimes two parts, sometimes three parts" part
>

​The machine representation of the version number is 6 digits without any
punctuation.

The human representation for version numbers >= 10 is two integers
separated using a full-stop/period/decimal "."

You would never write 10.0.2 instead of 10.2 just like you'd never write
1002 instead of 12

​You only have to do more than one thing if you are using the wrong
representation and are trying to be robust.  While I understand that some
people may indeed be doing that or otherwise stuck in that unfortunate
circumstance accommodating their needs amounts to nothing other than
maintaining compatibility for unsupported usage.  I'll admit we probably
could have been more explicit on what we do consider proper usage - which
is why I have at least some sympathy for the position.

David J.


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake  wrote:
> 
> On 06/20/2016 10:45 AM, Mark Dilger wrote:
> 
>>> Now maybe you have some other idea in mind, but I don't quite
>>> understand what it is.
>> 
>> I do, indeed, and here it is:
>> 
>> When considering whether to *back port* a change, we typically do so
>> on the basis that bug fixes are back ported, features are not.  In my
>> proposed versioning scheme, you could back port any feature that is
>> compatible with the old version, and bump the middle number to alert
>> users that you've not just back ported a bug fix, but a feature.  Any new
>> features that are not compatible don't get back ported.
>> 
>> If you fix a bug on master during development, you can back port that
>> as well.  But instead of bumping the middle number, you bump the last
>> number.
>> 
>> Somebody running a version that is three major versions back could
>> still get the advantage of new features, so long as those new features
>> are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
>> as it is to run rpm -U.  You get downtime either way, but the elapsed
>> time of that downtime is orders of magnitude different.
>> 
>> Someone else running that same version from three major versions ago
>> can take a more conservative policy, and only upgrade bug fixes, and
>> forego the back ported features.
>> 
>> You still have one major version release per year.  At that time, you can
>> also release back-port versions of prior major versions.
> 
> OFFLIST:
> 
> You are fighting a losing if noble battle.

I think all my emails on this subject have been seriously misunderstood.
Perhaps the problem is that I don't understand some critical issue.  Can 
you please help me understand this part:

It seems like people want releases, starting with 10.0, to be named things
like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs
like nagios refer to them as 10.0.0, 10.0.1, 10.0.2

Is that right?

That's the part that really annoys me, and I keep trying to argue for not doing
that, and people keep replying to other parts of my messages rather than
replying to the core part of what I am saying.

Why would any sensible person want a release to sometimes be called
"10.4", but the exact same release sometimes referred to as "10.0.4"?
This is just going to confuse average software users, as they would never
expect that 10.4 and 10.0.4 are the same thing.

Have I misunderstood what is being proposed?

The only reason I talk about using the middle number for this other purpose
is to forestall people assuming that they can elide the middle number of a
three number system, such that it gets elided sometimes but not other times.
I was quite clear in my email this morning that I'm not arguing for a three
number system.  I'm perfectly ok with a two number system.  I just don't want
a "let's confuse everybody by making each and every release have two
different names" system.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Alvaro Herrera
Mark Dilger wrote:

> When considering whether to *back port* a change, we typically do so
> on the basis that bug fixes are back ported, features are not.  In my
> proposed versioning scheme, you could back port any feature that is
> compatible with the old version, and bump the middle number to alert
> users that you've not just back ported a bug fix, but a feature.  Any new
> features that are not compatible don't get back ported.

So instead of having about 5 branches to maintain, we will end up with
5N branches, because we will still have to support the initial .0
branches of each major, plus .1, .2 ... of each major branch?

Granted, we could have major releases not every year but perhaps every 2
or 3 years; non-catversion-bumping patches would still be released
quicker than that, in middle-number-increasing releases.  But like
Robert, I don't think that the number of features we could add this way
would be numerous enough to support this idea in the long run.

I think this increases the load on committers many times.  Count me out.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 20, 2016, at 9:38 AM, David G. Johnston  
> wrote:
> 
> On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger  wrote:
> 
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger  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.​..

I am not arguing for that.  I'm arguing against having two different versions 
of the
same thing.  If you go with a two part versioning scheme that is sometimes 
written as a
three part versioning scheme, you make every bit of code that deals with it 
from now on
have to deal with both possible versions in order to be robust.

My preference is to have a three part versioning scheme where all three parts 
have
different purposes.  But since the community seems to have no interest in that, 
and
have largely (if not universally) rejected that idea, I'm falling back to 
merely arguing
that if we're going to have a two part versioning system, we should do that 
everywhere,
and if we can't do that everywhere, then we should do that nowhere.

You appear to be arguing that we should have a versioning scheme that is 
sometimes
two parts, and sometimes three parts, but when three parts, always make the 
middle
number zero.  The part of that which bothers me most is not the "always zero" 
part.   It's
the "sometimes two parts, sometimes three parts" part.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 20, 2016, at 9:43 AM, Robert Haas  wrote:
> 
> On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger  wrote:
>>> In practical effect that is exactly what your proposal does.  You just feel 
>>> better because you defined when B is allowed to change even though it never 
>>> should happen based upon our project policy.  And any rare exception can 
>>> justifiably be called a bug fix because, face it, it would only happen if 
>>> someone reports a bug.
>> 
>> Why are you refusing to acknowledge the difference between features that 
>> require a pg_upgrade and features that don't?
> 
> The amount of additional committer work that would be created by
> making that distinction would be large.  Currently, we're on an annual
> release cycle.  Every commit that's not a bug fix gets committed to
> exactly one branch: master.  Inevitably, there are multiple changes
> per cycle - dozens, probably - that change initial catalog contents
> and would therefore require pg_upgrade.
> 
> Suppose we switched to a semi-annual release cycle where every other
> release required a pg_upgrade, so once per year same as now, and the
> other ones did not.  The only way to do that would be to have two
> active development branches, one of which accepts only changes that
> don't bump catversion or xlog_page_magic and the other of which
> accepts changes of all sorts.  Every patch that qualifies for the
> no-pg-upgrade-required branch would have to be committed twice,
> resolving conflicts as necessary.
> 
> Also, over time, the number of supported branches would approximately
> double.  With a five year support window, it's currently about six.
> If you had another set of semi-major releases in between the main set
> of releases, you'd end up with 11 or 12 active branches, which would
> make back-patching significantly more burdensome than currently.
> 
> Now maybe you have some other idea in mind, but I don't quite
> understand what it is. 

I do, indeed, and here it is:

When considering whether to *back port* a change, we typically do so
on the basis that bug fixes are back ported, features are not.  In my
proposed versioning scheme, you could back port any feature that is
compatible with the old version, and bump the middle number to alert
users that you've not just back ported a bug fix, but a feature.  Any new
features that are not compatible don't get back ported.

If you fix a bug on master during development, you can back port that
as well.  But instead of bumping the middle number, you bump the last
number.

Somebody running a version that is three major versions back could
still get the advantage of new features, so long as those new features
are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
as it is to run rpm -U.  You get downtime either way, but the elapsed
time of that downtime is orders of magnitude different.

Someone else running that same version from three major versions ago
can take a more conservative policy, and only upgrade bug fixes, and
forego the back ported features.

You still have one major version release per year.  At that time, you can
also release back-port versions of prior major versions.



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Robert Haas
On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger  wrote:
>> In practical effect that is exactly what your proposal does.  You just feel 
>> better because you defined when B is allowed to change even though it never 
>> should happen based upon our project policy.  And any rare exception can 
>> justifiably be called a bug fix because, face it, it would only happen if 
>> someone reports a bug.
>
> Why are you refusing to acknowledge the difference between features that 
> require a pg_upgrade and features that don't?

The amount of additional committer work that would be created by
making that distinction would be large.  Currently, we're on an annual
release cycle.  Every commit that's not a bug fix gets committed to
exactly one branch: master.  Inevitably, there are multiple changes
per cycle - dozens, probably - that change initial catalog contents
and would therefore require pg_upgrade.

Suppose we switched to a semi-annual release cycle where every other
release required a pg_upgrade, so once per year same as now, and the
other ones did not.  The only way to do that would be to have two
active development branches, one of which accepts only changes that
don't bump catversion or xlog_page_magic and the other of which
accepts changes of all sorts.  Every patch that qualifies for the
no-pg-upgrade-required branch would have to be committed twice,
resolving conflicts as necessary.

Also, over time, the number of supported branches would approximately
double.  With a five year support window, it's currently about six.
If you had another set of semi-major releases in between the main set
of releases, you'd end up with 11 or 12 active branches, which would
make back-patching significantly more burdensome than currently.

Now maybe you have some other idea in mind, but I don't quite
understand what it is.  It's not likely to ever happen that we go
through a whole 12 month release cycle and then get to the end of it
and say "huh, I guess we never bumped catversion or xlog_page_magic".
If that ever does happen, it's probably a sign that nobody is doing
any meaningful feature development any more.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger 
wrote:

>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger 
> 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.


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 20, 2016, at 8:53 AM, Mark Dilger  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.


mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger
> 
> In practical effect that is exactly what your proposal does.  You just feel 
> better because you defined when B is allowed to change even though it never 
> should happen based upon our project policy.  And any rare exception can 
> justifiably be called a bug fix because, face it, it would only happen if 
> someone reports a bug.

Why are you refusing to acknowledge the difference between features that 
require a pg_upgrade and features that don't?



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-20 Thread David G. Johnston
On Monday, June 20, 2016, Mark Dilger  wrote:

>
> > On Jun 18, 2016, at 5:48 PM, Josh Berkus  > wrote:
> >
> > On 06/16/2016 11:01 PM, Craig Ringer wrote:
> >>
> >> I thought about raising this, but I think in the end it's replacing one
> >> confusing and weird versioning scheme for another confusing and weird
> >> versioning scheme.
> >>
> >> It does have the advantage that that compare a two-part major like
> >> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
> >> since it'll be 11 and 12. So it's more backward-compatible. But
> >> ugly.
> >>
> >
> > Realistically, though, we're more likely to end up with 10.0.1 than
> > 10.1.  I don't think we're anywhere near plumbing the depths of the
> > stuff which will break because folks are parsing our version numbers
> > with regexes.  In more major software, this will break nagios
> > check_postgres.
>
> Having a 3 part versioning scheme where the middle portion is always
> zero makes the least sense to me of any of the proposals.  If we're going
> to have the pain and hurting of moving to a 2 part versioning scheme,
> and breaking nagios and what not, then lets just get on with it.  If we're
> going to keep all three parts, can we please use my proposal earlier in
> this thread where A.B.C are allocated for:
>
> C++:  bug fixes only
> B++:  new features added, but still backward compatible with prior version
> A++:  new features added, not backward compatible, pg_upgrade required
>
> If every new feature release ends up requiring pg_upgrade, then B will
> always be zero, which is no worse than your proposal.  But at least users
> can
> refer to part B to learn something useful, namely whether they will need to
> run pg_upgrade as part of upgrading their existing cluster.
>
> This has the advantage that new minor features, like adding a new guc, can
> be released sooner than the next major release, but does not have to be
> released in disguise as if it were a bug fix.
>
> 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.
>
>
In practical effect that is exactly what your proposal does.  You just feel
better because you defined when B is allowed to change even though it never
should happen based upon our project policy.  And any rare exception can
justifiably be called a bug fix because, face it, it would only happen if
someone reports a bug.

If we keep the middle digit it will be for compatibility reasons.  Let's
not cause people to infer something that isn't true by saying it could
change.

David J.


Re: [HACKERS] 10.0

2016-06-20 Thread Mark Dilger

> On Jun 18, 2016, at 5:48 PM, Josh Berkus  wrote:
> 
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>> 
>> I thought about raising this, but I think in the end it's replacing one
>> confusing and weird versioning scheme for another confusing and weird
>> versioning scheme.
>> 
>> It does have the advantage that that compare a two-part major like
>> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
>> since it'll be 11 and 12. So it's more backward-compatible. But
>> ugly.
>> 
> 
> Realistically, though, we're more likely to end up with 10.0.1 than
> 10.1.  I don't think we're anywhere near plumbing the depths of the
> stuff which will break because folks are parsing our version numbers
> with regexes.  In more major software, this will break nagios
> check_postgres.

Having a 3 part versioning scheme where the middle portion is always
zero makes the least sense to me of any of the proposals.  If we're going
to have the pain and hurting of moving to a 2 part versioning scheme,
and breaking nagios and what not, then lets just get on with it.  If we're
going to keep all three parts, can we please use my proposal earlier in
this thread where A.B.C are allocated for:

C++:  bug fixes only
B++:  new features added, but still backward compatible with prior version
A++:  new features added, not backward compatible, pg_upgrade required

If every new feature release ends up requiring pg_upgrade, then B will
always be zero, which is no worse than your proposal.  But at least users can
refer to part B to learn something useful, namely whether they will need to
run pg_upgrade as part of upgrading their existing cluster.

This has the advantage that new minor features, like adding a new guc, can
be released sooner than the next major release, but does not have to be
released in disguise as if it were a bug fix.

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.

mark


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-18 Thread David Fetter
On Sat, Jun 18, 2016 at 05:48:30PM -0700, Josh Berkus wrote:
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
> > 
> > I thought about raising this, but I think in the end it's replacing one
> > confusing and weird versioning scheme for another confusing and weird
> > versioning scheme.
> > 
> > It does have the advantage that that compare a two-part major like
> > 090401 vs 090402 won't be confused when they compare 100100 and 100200,
> > since it'll be 11 and 12. So it's more backward-compatible. But
> > ugly.
> 
> Realistically, though, we're more likely to end up with 10.0.1 than
> 10.1.  I don't think we're anywhere near plumbing the depths of the
> stuff which will break because folks are parsing our version numbers
> with regexes.  In more major software, this will break nagios
> check_postgres.
> 
> I'm not happy with it, but I believe that's where we'll end up.

Pulling back a bit from this a bit, I am pretty sure that the fix for
the new announced version numbers, so long as our new policy is clear
and won't be changed again for the foreseeable future has the
following characteristics:

- Not a show-stopper, i.e. people will not drop support in their
  products for PostgreSQL over this.

- A Matter of Programming that really is small.  The difference
  between the old three-part/six-digit version encoding and the new
  two-part/four-digit version encoding is stark and simple, as is the
  code to handle it, even if it's regex.  By the time we get to
  PostgreSQL 100.0, the first starship will already be back, and the
  9.x PostgreSQLs will be in older to people using them then that the
  Zuse Z1 https://en.wikipedia.org/wiki/Konrad_Zuse is to us now.

Just my $.02.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-18 Thread Josh Berkus
On 06/16/2016 11:01 PM, Craig Ringer wrote:
> 
> I thought about raising this, but I think in the end it's replacing one
> confusing and weird versioning scheme for another confusing and weird
> versioning scheme.
> 
> It does have the advantage that that compare a two-part major like
> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
> since it'll be 11 and 12. So it's more backward-compatible. But
> ugly.
> 

Realistically, though, we're more likely to end up with 10.0.1 than
10.1.  I don't think we're anywhere near plumbing the depths of the
stuff which will break because folks are parsing our version numbers
with regexes.  In more major software, this will break nagios
check_postgres.

I'm not happy with it, but I believe that's where we'll end up.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-17 Thread Josh Berkus
On 06/17/2016 10:04 AM, Alvaro Herrera wrote:
> Merlin Moncure wrote:
> 
>> Ugliness is a highly subjective qualifier.  OTOH, Backwards
>> compatibility, at least when the checks are properly written :-), is a
>> very objective benefit.
> 
> This is the argument that made us kept the PostgreSQL name instead of
> renaming back to Postgres.  I'm not a fan of it.
> 

Well ... no.

We kept the PostgreSQL name for three reasons.

Back in 2005, which was the last time we could have reasonably changed
it, nobody had the time/energy to do all of the
search-and-replace-and-contact-every-packager required.  The folks who
were most enthusiastic about the change wanted someone else to do the
work.  Plus, our Japanese community, which was like 40% of our worldwide
community at the time, was opposed to the change.

The third reason is that we have a registered trademark on "PostgreSQL",
but "postgres" is public domain.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-17 Thread Robert Haas
On Fri, Jun 17, 2016 at 1:04 PM, Alvaro Herrera
 wrote:
> Merlin Moncure wrote:
>
>> Ugliness is a highly subjective qualifier.  OTOH, Backwards
>> compatibility, at least when the checks are properly written :-), is a
>> very objective benefit.
>
> This is the argument that made us kept the PostgreSQL name instead of
> renaming back to Postgres.  I'm not a fan of it.

I, on the other hand, am a big fan of backward-compatibility.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-17 Thread Alvaro Herrera
Merlin Moncure wrote:

> Ugliness is a highly subjective qualifier.  OTOH, Backwards
> compatibility, at least when the checks are properly written :-), is a
> very objective benefit.

This is the argument that made us kept the PostgreSQL name instead of
renaming back to Postgres.  I'm not a fan of it.

-- 
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-17 Thread Merlin Moncure
On Fri, Jun 17, 2016 at 1:01 AM, Craig Ringer  wrote:
> On 17 June 2016 at 08:34, Greg Stark  wrote:
>>
>> So we would release 10.0.0 and 10.0.1 and the next major release would be
>> 11.0.0.
>>
>> This would have two benefits:
>>
>> 1) It emphasises that minor releases continue to be safe minor updates
>> that offer the same stability guarantees. Users would be less likely to be
>> intimidated by 10.0.1 than they would be 10.1. And it gives users a
>> consistent story they can apply to any version whether 9.x or 10.0+
>
>
> And matches semver.
>
>>
>> 2) If we ever do release incompatible feature releases on older branches
>> -- or more likely some fork does -- it gives them a natural way to number
>> their release.
>
> Seems unlikely, though.
>
> I thought about raising this, but I think in the end it's replacing one
> confusing and weird versioning scheme for another confusing and weird
> versioning scheme.
>
> It does have the advantage that that compare a two-part major like 090401 vs
> 090402 won't be confused when they compare 100100 and 100200, since it'll be
> 11 and 12. So it's more backward-compatible. But ugly.

Ugliness is a highly subjective qualifier.  OTOH, Backwards
compatibility, at least when the checks are properly written :-), is a
very objective benefit.

merlin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-17 Thread David G. Johnston
On Fri, Jun 17, 2016 at 2:01 AM, Craig Ringer  wrote:

> On 17 June 2016 at 08:34, Greg Stark  wrote:
>
>> So we would release 10.0.0 and 10.0.1 and the next major release would be
>> 11.0.0.
>>
>> This would have two benefits:
>>
>> 1) It emphasises that minor releases continue to be safe minor updates
>> that offer the same stability guarantees. Users would be less likely to be
>> intimidated by 10.0.1 than they would be 10.1. And it gives users a
>> consistent story they can apply to any version whether 9.x or 10.0+
>>
>
> And matches semver.
>

​If we were or ever expected to have some kind of semver policy then a
numbering scheme matching semver would make sense.  We don't and so having
one just allows people to make invalid assumptions.​

​This possibility was known when the discussion at pgCon happened and,
IIUC, the decision to use 10.0 was made.  And this thread went on for quite
a while prior to that.  Lets let this die, please.  Or at worse wait until
we open HEAD up for 10.0 and someone commits the fully fleshed out
versioning changes to the docs.

David J.
​


Re: [HACKERS] 10.0

2016-06-17 Thread Craig Ringer
On 17 June 2016 at 08:34, Greg Stark  wrote:

> So we would release 10.0.0 and 10.0.1 and the next major release would be
> 11.0.0.
>
> This would have two benefits:
>
> 1) It emphasises that minor releases continue to be safe minor updates
> that offer the same stability guarantees. Users would be less likely to be
> intimidated by 10.0.1 than they would be 10.1. And it gives users a
> consistent story they can apply to any version whether 9.x or 10.0+
>

And matches semver.


> 2) If we ever do release incompatible feature releases on older branches
> -- or more likely some fork does -- it gives them a natural way to number
> their release.
>
Seems unlikely, though.

I thought about raising this, but I think in the end it's replacing one
confusing and weird versioning scheme for another confusing and weird
versioning scheme.

It does have the advantage that that compare a two-part major like 090401
vs 090402 won't be confused when they compare 100100 and 100200, since
it'll be 11 and 12. So it's more backward-compatible. But ugly.


-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: [HACKERS] 10.0

2016-06-16 Thread Craig Ringer
On 15 June 2016 at 06:48, David G. Johnston 
wrote:


>
> ​We could stand to be more explicit here.  The docs for version()
> indicated the server_version_num should be used for "machine processing".
>
> The implied correct way to access the canonical server version is thus:
>
> SELECT current_setting('server_version_num');
>
>
Or get server_version from the GUC_REPORT params sent at connect-time,
avoiding a round-trip. That's how drivers do it.

Client application should just ask their driver, they shouldn't need to be
poking around to get the version directly.

It'd be better if server_version_num was also GUC_REPORT, but it isn't. I
still think it should be.



-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: [HACKERS] 10.0

2016-06-16 Thread Greg Stark
On 15 Jun 2016 2:59 pm, "David G. Johnston" 
wrote:
>
> IIRC the plan is to have the machine version behave as if the middle
number is present and always zero.  It would be (the?) one place that the
historical behavior remains visible but it is impossible to have a totally
clean break.

I haven't been keeping up with hackers, sorry if this has been suggested
already but...

Why don't we just *actually* keep the middle digit and *actually* have it
always be zero?

So we would release 10.0.0 and 10.0.1 and the next major release would be
11.0.0.

This would have two benefits:

1) It emphasises that minor releases continue to be safe minor updates that
offer the same stability guarantees. Users would be less likely to be
intimidated by 10.0.1 than they would be 10.1. And it gives users a
consistent story they can apply to any version whether 9.x or 10.0+

2) If we ever do release incompatible feature releases on older branches --
or more likely some fork does -- it gives them a natural way to number
their release.


Re: [HACKERS] 10.0

2016-06-15 Thread Jim Nasby

On 6/15/16 9:04 AM, Merlin Moncure wrote:

We could stand to be more explicit here.  The docs for version()
>> > indicated
>> > the server_version_num should be used for "machine processing".


On a somewhat related note, any objection to adding server_version_num 
to pg_config? It's common to need to know what version you're handling 
in a Makefile, and today that's pretty ugly (especially when something 
is stamped as beta, since it breaks assumptions about numeric).

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-15 Thread Merlin Moncure
On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston
 wrote:
> On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure  wrote:
>>
>> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
>>  wrote:
>> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure 
>> > wrote:
>> >>
>> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby 
>> >> wrote:
>> >> > On 6/14/16 3:56 PM, Tom Lane wrote:
>> >> >>
>> >> >> Jim Nasby  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.
>> >>
>> >> Right.  It's the only way to handle things on the SQL level well,
>> >> that, and pg_settings approaches.  In other words, there is no easier
>> >> way.  I think it's pretty reasonable to assume there's a lot more code
>> >> interfacing with the database from SQL than from C.
>> >
>> >
>> > We could stand to be more explicit here.  The docs for version()
>> > indicated
>> > the server_version_num should be used for "machine processing".
>>
>> whoop! I didn't know about that setting.  I guess it dismantles a lot
>> of the case for more aggressive action.  That said, maybe it's a good
>> idea to construct the versioning change so that 10.x releases have a
>> server_version_num > 9.x releases and leave the other functions alone
>> (assuming that wasn't already the plan).
>>
>> > Option E: Give the DBA control.  If they know they have one or more
>> > mis-behaving applications but it is out their control to patch the code
>> > to
>> > work properly they can change this supposedly human-readable output to
>> > conform the historical x.y.z format.  This would disabled by default.
>> > Humans can easily interpret both versions so please save the comment
>> > about
>> > not having GUCs that influence user-visible behavior.  If your argument
>> > for
>> > changing the format outright is "its for human consumption only" then
>> > apparently this output should not be considered important enough to
>> > adhere
>> > to that rule.  Non-humans depending on its format are subject to our, or
>> > the
>> > DBA's, whims.
>>
>> Nah -- my argument could be restated as "I wasn't aware of the machine
>> variant of the version #".  Do you think it's a good idea to have the
>> machine version number be 10 for version 10.0?  What would 10.1
>> be?  100100 or 11?
>
>
> Sleeping on it I too came to the conclusion that the GUC was largely an
> undesirable option.
>
> IIRC the plan is to have the machine version behave as if the middle number
> is present and always zero.  It would be (the?) one place that the
> historical behavior remains visible but it is impossible to have a totally
> clean break.
>
> Tom's comment back on May 14th (different thread) was that we'd basically
> redefine the minor portion to be 4-digits instead of 2.

That makes sense -- I'm good then.  Thanks for engaging

merlin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-15 Thread David G. Johnston
On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure  wrote:

> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
>  wrote:
> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure 
> wrote:
> >>
> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby 
> >> wrote:
> >> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >> >>
> >> >> Jim Nasby  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.
> >>
> >> Right.  It's the only way to handle things on the SQL level well,
> >> that, and pg_settings approaches.  In other words, there is no easier
> >> way.  I think it's pretty reasonable to assume there's a lot more code
> >> interfacing with the database from SQL than from C.
> >
> >
> > We could stand to be more explicit here.  The docs for version()
> indicated
> > the server_version_num should be used for "machine processing".
>
> whoop! I didn't know about that setting.  I guess it dismantles a lot
> of the case for more aggressive action.  That said, maybe it's a good
> idea to construct the versioning change so that 10.x releases have a
> server_version_num > 9.x releases and leave the other functions alone
> (assuming that wasn't already the plan).
>
> > Option E: Give the DBA control.  If they know they have one or more
> > mis-behaving applications but it is out their control to patch the code
> to
> > work properly they can change this supposedly human-readable output to
> > conform the historical x.y.z format.  This would disabled by default.
> > Humans can easily interpret both versions so please save the comment
> about
> > not having GUCs that influence user-visible behavior.  If your argument
> for
> > changing the format outright is "its for human consumption only" then
> > apparently this output should not be considered important enough to
> adhere
> > to that rule.  Non-humans depending on its format are subject to our, or
> the
> > DBA's, whims.
>
> Nah -- my argument could be restated as "I wasn't aware of the machine
> variant of the version #".  Do you think it's a good idea to have the
> machine version number be 10 for version 10.0?  What would 10.1
> be?  100100 or 11?


​Sleeping on it I too came to the conclusion that the GUC was largely an
undesirable option.

IIRC the plan is to have the machine version behave as if the middle number
is present and always zero.  It would be (the?) one place that the
historical behavior remains visible but it is impossible to have a totally
clean break.
​
​

Tom's comment back on May 14th (different thread) was that we'd basically
redefine the minor portion to be 4-digits instead of 2.

David J.​


Re: [HACKERS] 10.0

2016-06-15 Thread Merlin Moncure
On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
 wrote:
> On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure  wrote:
>>
>> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby 
>> wrote:
>> > On 6/14/16 3:56 PM, Tom Lane wrote:
>> >>
>> >> Jim Nasby  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.
>>
>> Right.  It's the only way to handle things on the SQL level well,
>> that, and pg_settings approaches.  In other words, there is no easier
>> way.  I think it's pretty reasonable to assume there's a lot more code
>> interfacing with the database from SQL than from C.
>
>
> We could stand to be more explicit here.  The docs for version() indicated
> the server_version_num should be used for "machine processing".

whoop! I didn't know about that setting.  I guess it dismantles a lot
of the case for more aggressive action.  That said, maybe it's a good
idea to construct the versioning change so that 10.x releases have a
server_version_num > 9.x releases and leave the other functions alone
(assuming that wasn't already the plan).

> Option E: Give the DBA control.  If they know they have one or more
> mis-behaving applications but it is out their control to patch the code to
> work properly they can change this supposedly human-readable output to
> conform the historical x.y.z format.  This would disabled by default.
> Humans can easily interpret both versions so please save the comment about
> not having GUCs that influence user-visible behavior.  If your argument for
> changing the format outright is "its for human consumption only" then
> apparently this output should not be considered important enough to adhere
> to that rule.  Non-humans depending on its format are subject to our, or the
> DBA's, whims.

Nah -- my argument could be restated as "I wasn't aware of the machine
variant of the version #".  Do you think it's a good idea to have the
machine version number be 10 for version 10.0?  What would 10.1
be?  100100 or 11?

merlin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Joshua D. Drake

On 06/14/2016 05:08 PM, Cat wrote:


We have the capability to provide (semi-)structured data. Might be an idea
to make greater use of it.



postgres=# SELECT * from 
to_json(row(current_setting('server_version_num'))) as version;



Sincerely,

jD

--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Vik Fearing
On 15/06/16 02:08, Cat wrote:
> is it possible to introduce a JSONB output to it.

No thanks.
-- 
Vik Fearing  +33 6 46 75 15 36
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Cat
On Tue, Jun 14, 2016 at 01:38:44PM -0700, Joshua D. Drake wrote:
> On 06/14/2016 12:46 PM, Jim Nasby wrote:
> 
> >Any ideas on naming for such a function? version_detail()? I suppose
> >while we're at this we might as well provide the compile details as well.
> 
> version(detail) or version(verbose)

If we're looking at forward only changes, is it possible to introduce a
JSONB output to it. Then people can rip out whichever component they want
at will.

For example:

{
"full": 10.0,
"major": 10,
"patchlevel": 0
}

and whatever else may be pertinent. I used numeric types above but they
can be strings if that works better.

We have the capability to provide (semi-)structured data. Might be an idea
to make greater use of it.

-- 
  "A search of his car uncovered pornography, a homemade sex aid, women's 
  stockings and a Jack Russell terrier."
- 
http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-118083480


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread David G. Johnston
On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure  wrote:

> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby 
> wrote:
> > On 6/14/16 3:56 PM, Tom Lane wrote:
> >>
> >> Jim Nasby  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.
>
> Right.  It's the only way to handle things on the SQL level well,
> that, and pg_settings approaches.  In other words, there is no easier
> way.  I think it's pretty reasonable to assume there's a lot more code
> interfacing with the database from SQL than from C.
>

​We could stand to be more explicit here.  The docs for version() indicated
the server_version_num should be used for "machine processing".

The implied correct way to access the canonical server version is thus:

SELECT current_setting('server_version_num');

I'd say we should at least provide the above as an example; the reader can
find their way to Chapter 18.1 if they are curious about alternatives.

​On the topic of option "D" I'd be fine with fine with functions:
   and ; but that is
independent of this discussion.

Option E: Give the DBA control.  If they know they have one or more
mis-behaving applications but it is out their control to patch the code to
work properly they can change this supposedly human-readable output to
conform the historical x.y.z format.  This would disabled by default.
Humans can easily interpret both versions so please save the comment about
not having GUCs that influence user-visible behavior.  If your argument for
changing the format outright is "its for human consumption only" then
apparently this output should not be considered important enough to adhere
to that rule.  Non-humans depending on its format are subject to our, or
the DBA's, whims.

David J.


Re: [HACKERS] 10.0

2016-06-14 Thread Merlin Moncure
On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby  wrote:
> On 6/14/16 3:56 PM, Tom Lane wrote:
>>
>> Jim Nasby  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.

Right.  It's the only way to handle things on the SQL level well,
that, and pg_settings approaches.  In other words, there is no easier
way.  I think it's pretty reasonable to assume there's a lot more code
interfacing with the database from SQL than from C.

merlin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Jim Nasby

On 6/14/16 3:56 PM, Tom Lane wrote:

Jim Nasby  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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Jim Nasby

On 6/14/16 3:38 PM, Joshua D. Drake wrote:

On 06/14/2016 12:46 PM, Jim Nasby wrote:


Any ideas on naming for such a function? version_detail()? I suppose
while we're at this we might as well provide the compile details as well.


version(detail) or version(verbose)


I don't think that makes as much sense as a different function name, 
since the output is fundamentally different than version().

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Tom Lane
Jim Nasby  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.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Jim Nasby

On 6/14/16 3:01 PM, Robert Haas wrote:

D) Add a version function to 10.0 that returns both parts separately.
>
> My vote is D. Parsing version() output is a wart, but coming out with a
> split output version of that in 9.6 that still has to support 3 numbers
> would also be a wart. We've lived with the parsing wart this long, so lets
> just add an explicit output version to 10.0.
>
> Any ideas on naming for such a function? version_detail()? I suppose while
> we're at this we might as well provide the compile details as well.

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. So 
no matter what, you won't be able to use it if you're interested in 
<10.0 (or <9.6 if we went with one of the other proposals).


Unless folks were thinking this is something that would be backpatched?
--
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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Joshua D. Drake

On 06/14/2016 12:46 PM, Jim Nasby wrote:


Any ideas on naming for such a function? version_detail()? I suppose
while we're at this we might as well provide the compile details as well.


version(detail) or version(verbose)

JD

--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Robert Haas
On Tue, Jun 14, 2016 at 3:46 PM, Jim Nasby  wrote:
> On 6/13/16 2:12 PM, Merlin Moncure wrote:
>>
>> A) make a variant of version() that returns major/minor/bugfix as
>> separate fields with minor being set to 0 for all released versions
>> 10.0 and beyond.  We could then add a NOTE to the version function and
>> other places suggesting to use that instead for 9.6.
>>
>> B) Preserve x.y.z as returned by version() and show server_version for
>> those usages only, with 'y' being always 0 for 10.0 and beyond.  For
>> all other purposes (marketing/documentation/etc) that structure would
>> *not* be preserved, and we would put notes in the documentation
>> describing why the extra digit is there.
>>
>> C) Do neither A or B, and let our users discover such issues on their own.
>
>
> D) Add a version function to 10.0 that returns both parts separately.
>
> My vote is D. Parsing version() output is a wart, but coming out with a
> split output version of that in 9.6 that still has to support 3 numbers
> would also be a wart. We've lived with the parsing wart this long, so lets
> just add an explicit output version to 10.0.
>
> Any ideas on naming for such a function? version_detail()? I suppose while
> we're at this we might as well provide the compile details as well.

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-14 Thread Jim Nasby

On 6/13/16 2:12 PM, Merlin Moncure wrote:

A) make a variant of version() that returns major/minor/bugfix as
separate fields with minor being set to 0 for all released versions
10.0 and beyond.  We could then add a NOTE to the version function and
other places suggesting to use that instead for 9.6.

B) Preserve x.y.z as returned by version() and show server_version for
those usages only, with 'y' being always 0 for 10.0 and beyond.  For
all other purposes (marketing/documentation/etc) that structure would
*not* be preserved, and we would put notes in the documentation
describing why the extra digit is there.

C) Do neither A or B, and let our users discover such issues on their own.


D) Add a version function to 10.0 that returns both parts separately.

My vote is D. Parsing version() output is a wart, but coming out with a 
split output version of that in 9.6 that still has to support 3 numbers 
would also be a wart. We've lived with the parsing wart this long, so 
lets just add an explicit output version to 10.0.


Any ideas on naming for such a function? version_detail()? I suppose 
while we're at this we might as well provide the compile details as well.

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-06-13 Thread Merlin Moncure
On Tue, May 17, 2016 at 12:45 AM, Craig Ringer  wrote:
> On 14 May 2016 at 02:49, Tom Lane  wrote:
>>
>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>>
>> * Next year's major release will be 10.0, with minor updates 10.1,
>> 10.2, etc.
>>
>> * The year after, 11.0.  Etc cetera.
>>
>
> Yes. Please!
>
> I get tired of explaining to people that PostgreSQL "9.x" isn't a thing,
> that yes, 9.3 and 9.4 really _do_ have incompatible data directories and
> replication protocols, and that when the docs say "major version" they don't
> mean "major version as you might actually expect" but "first two version
> number parts".
>
> Lets get rid of this user-baffling wart.

Agreed.  What's been nagging me is what the impacts to users could be.
I just stumbled across some code that *could* have been broken, but by
sheer luck it's safe:

  /* only postgres 9.3+ supports row count from 'COPY' */
  IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3
  THEN
GET DIAGNOSTICS _RowCount = ROW_COUNT;
  ELSE
_RowCount := (LineCount(_ScratchFileName,
  (SELECT WorkFolder FROM CDSControl)))::BIGINT - 1;
  END IF;

LineCount() is a pl/sh wrapper to 'wc -l' that supports this wrapper
to COPY so that it always gives a count of rows loaded.  I guess this
is a pretty hacky way of doing version checks inside of SQL but I
suppose changing the structure of the version number might break
similar approaches to parsing the string.  This regex would in fact
continue to work properly, but it did raise some alarm bells.

Looking ahad, IMO we could:

A) make a variant of version() that returns major/minor/bugfix as
separate fields with minor being set to 0 for all released versions
10.0 and beyond.  We could then add a NOTE to the version function and
other places suggesting to use that instead for 9.6.

B) Preserve x.y.z as returned by version() and show server_version for
those usages only, with 'y' being always 0 for 10.0 and beyond.  For
all other purposes (marketing/documentation/etc) that structure would
*not* be preserved, and we would put notes in the documentation
describing why the extra digit is there.

C) Do neither A or B, and let our users discover such issues on their own.

merlin


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-17 Thread Jaime Casanova
On 17 May 2016 at 10:37, David Steele  wrote:
> On 5/17/16 10:51 AM, David Fetter wrote:
>
>> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>>> On 14 May 2016 at 02:49, Tom Lane  wrote:
 * This year's major release will be 9.6.0, with minor updates 9.6.1,
 9.6.2, etc.  It's too late to do otherwise for this release cycle.

 * Next year's major release will be 10.0, with minor updates 10.1,
 10.2, etc.

 * The year after, 11.0.  Etc cetera.


>>> Yes. Please!
>>
>> Hear, hear!
>>
>> Sadly, we're too late for 9.6, but we can start with 10.0 and finish
>> this silliness once and for good.
>
> +1!
>

+1

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-17 Thread David Steele

On 5/17/16 10:51 AM, David Fetter wrote:

> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>> On 14 May 2016 at 02:49, Tom Lane  wrote:
>>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>>> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>>>
>>> * Next year's major release will be 10.0, with minor updates 10.1,
>>> 10.2, etc.
>>>
>>> * The year after, 11.0.  Etc cetera.
>>>
>>>
>> Yes. Please!
>
> Hear, hear!
>
> Sadly, we're too late for 9.6, but we can start with 10.0 and finish
> this silliness once and for good.

+1!

--
-David
da...@pgmasters.net


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-17 Thread David Fetter
On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
> On 14 May 2016 at 02:49, Tom Lane  wrote:
> > * This year's major release will be 9.6.0, with minor updates 9.6.1,
> > 9.6.2, etc.  It's too late to do otherwise for this release cycle.
> >
> > * Next year's major release will be 10.0, with minor updates 10.1,
> > 10.2, etc.
> >
> > * The year after, 11.0.  Etc cetera.
> >
> >
> Yes. Please!
> 
> I get tired of explaining to people that PostgreSQL "9.x" isn't a thing,
> that yes, 9.3 and 9.4 really _do_ have incompatible data directories and
> replication protocols, and that when the docs say "major version" they
> don't mean "major version as you might actually expect" but "first two
> version number parts".
> 
> Lets get rid of this user-baffling wart.

Hear, hear!

Sadly, we're too late for 9.6, but we can start with 10.0 and finish
this silliness once and for good.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-16 Thread Craig Ringer
On 14 May 2016 at 02:49, Tom Lane  wrote:


>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.  Etc cetera.
>
>
Yes. Please!

I get tired of explaining to people that PostgreSQL "9.x" isn't a thing,
that yes, 9.3 and 9.4 really _do_ have incompatible data directories and
replication protocols, and that when the docs say "major version" they
don't mean "major version as you might actually expect" but "first two
version number parts".

Lets get rid of this user-baffling wart.

-- 
 Craig Ringer   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


Re: [HACKERS] 10.0

2016-05-16 Thread Jeff Janes
On Sat, May 14, 2016 at 8:37 PM, Tom Lane  wrote:
> Jeff Janes  writes:
>> There are lots of improvement which get done to in-memory data
>> structures that wouldn't require a pg_dump/pg_upgrade, which could in
>> principle be ported into prior major versions if we had the resources
>> (reviewing, testing, packaging) to do it, with an increase in the
>> middle number.  Maybe we will never find the resources to do that, but
>> why should that assumption get baked into the numbering scheme?
>
> If we were to do that today, it'd just be an increase in the minor number.
> I don't see why we'd need to change that approach.

We've rejected back-patching such improvements in the past on the
grounds that it was at least theoretically possible that it would
negatively affect someone, even if it were a win overall for most
people, and users shouldn't be forced to adopt that risk in order to
get security or corruption bug fixes that go into the minor number
increments.

> The real blocking
> factors there are about manpower and stability of the resulting code, not
> about whether you need some special version numbering to describe it.

If we did overcome the man-power and stability problems, we would
certain run into the version numbering one pretty quickly, under both
the existing versioning system and the two-part system.

And I don't think that using something at least vaguely like SemVer is
really "special", if anything it is less special than either the
existing or the dominant proposal.

Cheers,

Jeff


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-16 Thread Tom Lane
Peter Eisentraut  writes:
> On 5/16/16 9:53 AM, Greg Stark wrote:
>> I thought the idea was that Berkeley tossed an source tree over the
>> wall with no version number and then the first five releases were
>> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
>> Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
>> major release counting those as the first five releases.

> The last release out of Berkeley was 4.2.

Correct --- I have a copy of that tarball.

> Then Postgres95 was "5", and then PostgreSQL started at 6.

I wasn't actually around at the time, but our commit history starts
with this:

Author: Marc G. Fournier 
Branch: master Release: REL6_1 [d31084e9d] 1996-07-09 06:22:35 +

Postgres95 1.01 Distribution - Virgin Sources

The first mention of 6.anything is here:

Author: Bruce Momjian 
Branch: master Release: REL6_1 [a2b7f6297] 1996-12-28 02:01:58 +

Updated changes for 6.0.

I see no references in the commit history to 5.anything, but there
are some references like this:

Author: Marc G. Fournier 
Branch: master Release: REL6_1 [491b9b89c] 1996-08-26 20:38:52 +

The patch that is applied at the end of the email makes sure that these
conditions are always met. The patch can be applied to any version
of Postgres95 from 1.02 to 1.05. After applying the patch, queries
using indices on bpchar and varchar fields should (hopefully ;-) )
always return the same tuple set regardless to the fact whether
indices are used or not.
Submitted by: Gerhard Reithofer 

So I think that the Postgres95 releases were retrospectively redefined as
being the "5.x" series, but no release was ever made with such a number.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-16 Thread Peter Eisentraut

On 5/16/16 9:53 AM, Greg Stark wrote:

On Sat, May 14, 2016 at 1:00 AM, Tom Lane  wrote:


If that were the standard, we'd never have bumped the major version at
all, and would still be on 4.something (or whatever Berkeley was using
when they tossed it over the wall; I'm not too clear on whether there was
ever a 5.x release).


I thought the idea was that Berkeley tossed an source tree over the
wall with no version number and then the first five releases were
Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
major release counting those as the first five releases.


The last release out of Berkeley was 4.2.  Then Postgres95 was "5", and 
then PostgreSQL started at 6.


--
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-16 Thread Greg Stark
On Sat, May 14, 2016 at 1:00 AM, Tom Lane  wrote:

> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).

I thought the idea was that Berkeley tossed an source tree over the
wall with no version number and then the first five releases were
Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
major release counting those as the first five releases.

-- 
greg


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-15 Thread Jim Nasby

On 5/13/16 5:01 PM, Tom Lane wrote:

If we do decide to change the numbering strategy, there are quite a
few small details that probably ought to be fixed while we're at it.
I think it'd be a good idea to start separating "devel" or "betaN"
with a dot, for instance, like "10.devel" not "10devel".  But it's
likely premature to get into those sorts of details, since it's not
clear to me that we have a consensus to change at all.


It would be interesting to actually release snapshots after commit 
fests, ie: 10.dev.0, 10.dev.1, etc.


And +1 for ditching major.major.minor in favor of major.minor.0. It's 
high time we stop this silliness.


IMHO the beginning of parallelism that we have now is more than enough 
to justify 10.0, but that consideration pales compared to fixing the 
version numbering system itself.

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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-15 Thread Álvaro Hernández Tortosa



On 15/05/16 14:42, Magnus Hagander wrote:



On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa 
> wrote:




On 14/05/16 20:02, Petr Jelinek wrote:

+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.

It will hopefully both end these discussions and remove the
confusion the current versioning scheme has (I too heard way
to many times about people using postgres8 or postgres9).


Even worse: I've been told that a company was using
"PostgreSQL 8.5" ^_^


That's not necessarily the version numbers fault. That's them using an 
alpha version.. (Yes, I've run into a customer just a couple of years 
ago that were still on 8.5 alpha)





It was their fault, obviously. There were not using the alpha 
version, they were using 8.3 but they thought it was 8.5 (and yes, 
that's terrible that they provide information without checking it). 
Anyway, and not being version number's fault, having one less number may 
have helped here and probably in other cases too.


Álvaro

--
Álvaro Hernández Tortosa


---
8Kdata



Re: [HACKERS] 10.0

2016-05-15 Thread Magnus Hagander
On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa 
wrote:

>
>
> On 14/05/16 20:02, Petr Jelinek wrote:
>
>> +1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
>>
>> It will hopefully both end these discussions and remove the confusion the
>> current versioning scheme has (I too heard way to many times about people
>> using postgres8 or postgres9).
>>
>
> Even worse: I've been told that a company was using "PostgreSQL 8.5"
> ^_^


That's not necessarily the version numbers fault. That's them using an
alpha version.. (Yes, I've run into a customer just a couple of years ago
that were still on 8.5 alpha)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


Re: [HACKERS] 10.0

2016-05-15 Thread Álvaro Hernández Tortosa



On 14/05/16 20:02, Petr Jelinek wrote:

+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.

It will hopefully both end these discussions and remove the confusion 
the current versioning scheme has (I too heard way to many times about 
people using postgres8 or postgres9).


Even worse: I've been told that a company was using "PostgreSQL 
8.5" ^_^



Álvaro

--
Álvaro Hernández Tortosa


---
8Kdata



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-15 Thread Michael Paquier
On Sun, May 15, 2016 at 11:59 AM, Tom Lane  wrote:
> "Greg Sabino Mullane"  writes:
>> I think moving to a two-number format is a mistake: what exactly will
>> PQserverVersion() return in that case?
>
> For, say, 10.2 it would be 12, equivalent to 10.0.2 under old style.
>
> We could redefine it as being major plus four-digit minor, really.
> Under the current maintenance scheme we never get anywhere near minor
> release 99 before a branch dies ... but having some more breathing room
> there would not be a bad thing.

Perhaps that would be a good topic for the developer meeting in
Ottawa? That's just in two days, so it looks like a good timing.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Tom Lane
Jeff Janes  writes:
> There are lots of improvement which get done to in-memory data
> structures that wouldn't require a pg_dump/pg_upgrade, which could in
> principle be ported into prior major versions if we had the resources
> (reviewing, testing, packaging) to do it, with an increase in the
> middle number.  Maybe we will never find the resources to do that, but
> why should that assumption get baked into the numbering scheme?

If we were to do that today, it'd just be an increase in the minor number.
I don't see why we'd need to change that approach.  The real blocking
factors there are about manpower and stability of the resulting code, not
about whether you need some special version numbering to describe it.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Jeff Janes
On Sat, May 14, 2016 at 7:51 PM, Greg Sabino Mullane  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
>> Wasn't there some controversy about switching to major.minor versioning
>> this in -advocacy?
>>
>> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com
>
> I proposed in that thread that we always increment the first number,
> never increment the second number, and increment the third exactly as we do
> now for bugfix releases.

I like this idea, roughly in line with SemVer.

There are lots of improvement which get done to in-memory data
structures that wouldn't require a pg_dump/pg_upgrade, which could in
principle be ported into prior major versions if we had the resources
(reviewing, testing, packaging) to do it, with an increase in the
middle number.  Maybe we will never find the resources to do that, but
why should that assumption get baked into the numbering scheme?

Cheers,

Jeff


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Tom Lane
"Greg Sabino Mullane"  writes:
> I think moving to a two-number format is a mistake: what exactly will 
> PQserverVersion() return in that case?

For, say, 10.2 it would be 12, equivalent to 10.0.2 under old style.

We could redefine it as being major plus four-digit minor, really.
Under the current maintenance scheme we never get anywhere near minor
release 99 before a branch dies ... but having some more breathing room
there would not be a bad thing.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Greg Sabino Mullane

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


> Wasn't there some controversy about switching to major.minor versioning
> this in -advocacy?
>
> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com

I proposed in that thread that we always increment the first number, 
never increment the second number, and increment the third exactly as we do 
now for bugfix releases.

I think moving to a two-number format is a mistake: what exactly will 
PQserverVersion() return in that case? But I understand people have a hard 
time swallowing the "never change the middle number" portion of this idea.

Thus, here's a slight variation on that theme: what if we simply reversed the 
expectations of bumping the first number, and put the onus on people to 
change the *middle* number? Thus, the next release by default will be 10.0.0, 
the one after that will be by default 11.0.0, and so on. We can reserve the 
middle number for "lesser" releases - which may never happen - but at least 
we will have a mechanism to provide for them. So rather than the current spate 
of messages like this:

"This should be called 12.0 because of cool feature X and reason Y"

we would get the rare message like this:

"We don't really have much for this release, maybe it should just be 11.1?"


- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201605142247
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAlc34/UACgkQvJuQZxSWSsgQLgCeJS9v69R5C3BJxNy2ih1P2Tk8
xngAn0UQoSn6y3iOwMr5aHSKzuBh+3Xn
=wzw4
-END PGP SIGNATURE-




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Josh berkus
On 05/13/2016 07:18 PM, Mark Dilger wrote:
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.  It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been broken.  The major number is the normal
> place to do that.

The problem with that idea is that *minor* backwards compatibility
breakage is much more likely in each-and-every version than major
breakage is at any time in the foreseeable future.  The last major
breakage we really had was version 8.3, which if we'd been going by
compatibility should have been 9.0 (also for other reasons).

And if we adopt the "backwards compatibility" approach, then we'll just
be switching from the argument we're having now to the argument of "is
this enough breakage to rate a .0?  Yes/No?".  Which argument will be
just as long as this one.

So, my vote is now +1 to go to the 2-part numbering scheme.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Michael Banck
On Fri, May 13, 2016 at 08:55:20PM -0400, David G. Johnston wrote:
> The opinion seems to be that major.0 is some kind of magic incantation in
> the broader world of users...

>From my reading of the thread, while certainly that is the general
definition of a .0, having infrequent .0 releases is not very practical
for PostgreSQL because the major versions are not that different from
each other and all are treated the same development-wise. So it would be
a huge drain on the project to discuss which major version should be a
.0 unless planning towards them steps up significantly.

So I think the (slight) consensus is more that all major versions are
mostly equal and hence only one version number is needed.


Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Michael Banck
On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> The underlying premise, for me, of choosing .4 or .5  was that presently we
> discontinue support after 5 years/releases.  A new .0 would come out just
> as we discontinue the previous .0

Well maybe the 5 year support cycle would be nice to encode, but how is
.0 different from .1 then?  You make sound like .0 would be similar to
Ubuntu's LTS which is not the case, unless you want to propose that only
.0 releases get 5 years and not the in-betweens? That'd be a shame.

Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Petr Jelinek

+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.

It will hopefully both end these discussions and remove the confusion 
the current versioning scheme has (I too heard way to many times about 
people using postgres8 or postgres9).


For those saying this is version inflation. I don't see the problem, we 
are project with long history, which releases major version every year, 
I don't see why version number shouldn't reflect that.


About changing first digit only when we break compatibility with 
applications for example by removing money type. We do have app breaking 
incompatibilities in almost every major version so in effect we'd have 
to bump the first digit every time anyway if we went with that schema (I 
still remember working on db that was kept on 8.3 till EOL just because 
we changes hashtext implementation, or db which was kept back because of 
removal plgpsql rename clause where nobody wanted to rewrite couple 
thousand function which used it and there are many examples like that).


--
  Petr Jelinek  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Martín Marqués
El 13/05/16 a las 15:36, Josh berkus escribió:
> On 05/13/2016 11:31 AM, Alvaro Herrera wrote:
>> Josh berkus wrote:
>>  
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>>
>> I think the next version should be 10.0 no matter what changes we put
>> in.
>>
> 
> Well, if we adopt 2-part version numbers, it will be.  Maybe that's the
> easiest thing?  Then we never have to have this discussion again, which
> certainly appeals to me ...

Wasn't there some controversy about switching to major.minor versioning
this in -advocacy?

http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5...@biglumber.com

IMO, this versioning is pretty good and people understand it well, with
the other will be using postgres 13 by 2020, which isn't far away. ;)

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Martín Marqués
El 13/05/16 a las 15:31, Alvaro Herrera escribió:
> Josh berkus wrote:
>  
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
> 
> I think the next version should be 10.0 no matter what changes we put
> in.

+1

And another +1 on Tom's opinion on it being too late after beta1 has
been released.

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Joshua D. Drake

On 05/14/2016 07:08 AM, Robert Haas wrote:

On Fri, May 13, 2016 at 8:00 PM, Tom Lane  wrote:

Any project that starts inflating its numbering scheme sends a message to
users of the form, "hey, we've just been taken over by marketing people, and
software quality will go down from now on."


I don't think this is about version number inflation, but actually more
the opposite.  What you're calling the major number is really a marketing
number.  There is not a technical distinction between major releases where
we choose to bump the first number and those where we choose to bump the
second.  It's all about marketing.  So to me, merging those numbers would
be an anti-marketing move.  I think it's a good move: it would be more
honest and transparent about what the numbers mean, not less so.


"Marketing" and "honesty" are not antonyms, and thinking that
marketing is unimportant for the success of the project is not
correct.


+1

JD



--
Command Prompt, Inc.  http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Robert Haas
On Fri, May 13, 2016 at 11:39 AM, Tom Lane  wrote:
> Robert Haas  writes:
>> There is a long-running thread on pgsql-hackers on whether 9.6 should
>> instead be called 10.0.
>
> First I've seen it mentioned here.
>
> I think you are just about exactly one week too late to bring this up.
> Once we've shipped a beta, rebranding is way too confusing.

So, not that it makes any difference at this point, but this seems to
fly in the face of what you said before.

http://www.postgresql.org/message-id/24567.1456864...@sss.pgh.pa.us

Unless you thought that beta wasn't going to be out until the fall.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Robert Haas
On Fri, May 13, 2016 at 8:00 PM, Tom Lane  wrote:
>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, and
>> software quality will go down from now on."
>
> I don't think this is about version number inflation, but actually more
> the opposite.  What you're calling the major number is really a marketing
> number.  There is not a technical distinction between major releases where
> we choose to bump the first number and those where we choose to bump the
> second.  It's all about marketing.  So to me, merging those numbers would
> be an anti-marketing move.  I think it's a good move: it would be more
> honest and transparent about what the numbers mean, not less so.

"Marketing" and "honesty" are not antonyms, and thinking that
marketing is unimportant for the success of the project is not
correct.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Christoph Berg
Re: Álvaro Hernández Tortosa 2016-05-14 <5736f966.3040...@8kdata.com>
> Having said that, I believe having a single major number is a more
> effective marketing. Non major-major versions may make the release look like
> a "probably not worth" upgrade. People may hold their breath until a
> major-major upgrade, specially if people support this idea in forums like
> saying: "10.0 will come with amazing features, because version is bumped
> from 9.6".
> 
> So +1 to call 10.0 the next version and 11.0 the one after that.

+1.

Another data point: Debian did exactly this x.y.z -> x.y switch (with
exactly the same major/minor version number semantics re major/minor
upgrades) a few years ago [*], and it was a real relief. "Debian 9"
just sounds so much better than "Debian 9.6".

IMHO getting rid of the problem that people are always saying "I'm
using Postgres 9" when asked about the major version should be enough
reason to change to a x.y scheme.

Christoph

[*] There was a period of two releases where we bumped the x and y was
kept 0, before the y was ultimately dropped.
(3.0 - 3.1 - 4.0 - 5.0 - 6.0 - 7 - 8)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-14 Thread Álvaro Hernández Tortosa



On 14/05/16 02:00, Tom Lane wrote:

[...]

I don't think this is about version number inflation, but actually more
the opposite.  What you're calling the major number is really a marketing
number.  There is not a technical distinction between major releases where
we choose to bump the first number and those where we choose to bump the
second.  It's all about marketing.  So to me, merging those numbers would
be an anti-marketing move.  I think it's a good move: it would be more
honest and transparent about what the numbers mean, not less so.


If having two "major" numbers is a marketing game, and if it works 
in such a way, I'd immediately say let's keep it. Decisions like the one 
debated here should be driven more from what is going to help user 
adoption rather than -hackers personal taste. BTW, none of these 
approaches seem dishonest to me.


Having said that, I believe having a single major number is a more 
effective marketing. Non major-major versions may make the release look 
like a "probably not worth" upgrade. People may hold their breath until 
a major-major upgrade, specially if people support this idea in forums 
like saying: "10.0 will come with amazing features, because version is 
bumped from 9.6".


So +1 to call 10.0 the next version and 11.0 the one after that.

Álvaro

--
Álvaro Hernández Tortosa


---
8Kdata



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-13 Thread Mark Dilger

> On May 13, 2016, at 8:26 PM, David G. Johnston  
> wrote:
> 
> On Fri, May 13, 2016 at 10:18 PM, Mark Dilger  wrote:
> 
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence. 
> 
> ​​You started this sub-thread with:
> 
> "If I understand correctly..."
> 
> ​I'm not sure that you do...​
> 
> Our scheme is, in your terms, basically:
> 
> .micro
> 
> where  is a decimal.
> 
> You cannot reason about the whole and fraction portions of the decimal 
> independently.

There is no point in having them as separate parts of the version number
unless you can do precisely that.  If the only difference between choosing 9.7.0
vs. 10.0.0 is that you consulted a numerologist who moonlights as an astrologer,
then, yes, you can't tell anything from the first number independent from
the second.  I was simply arguing against the numerology/astrology approach
to version numbering.  The only other way out of the numerology/astrology
approach is the one Tom Lane suggested, and that you seem to support.

This whole conversation makes me think the community has done a poor job
of communicating the nature of the (major,minor) portion of the 
(major,minor,micro)
numbering scheme.  I always assumed it was more respectable that it now
appears to have been.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-13 Thread David G. Johnston
On Fri, May 13, 2016 at 10:18 PM, Mark Dilger 
wrote:

>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.


​​You started this sub-thread with:

"If I understand correctly..."

​I'm not sure that you do...​

Our scheme is, in your terms, basically:

.micro

where  is a decimal.

You cannot reason about the whole and fraction portions of the decimal
independently.

When  changes backward compatibility can be broken - with respect to
both API and implementation.

It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been broken.  The major number is the normal
> place to do that.


​I'm not convinced there is enough risk here to compromise the present in
order to accommodate some unknown ​scenario that may never even come to
pass.

David J.


Re: [HACKERS] 10.0

2016-05-13 Thread Mark Dilger

> On May 13, 2016, at 6:33 PM, David G. Johnston  
> wrote:
> 
> On Fri, May 13, 2016 at 7:32 PM, Mark Dilger  wrote:
> 
> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people, and
> software quality will go down from now on."
> 
> ​Tom brought up my own thoughts on the rest - but, really, this is a cynical 
> way of looking at things.

Every company I have worked for that has been taken over by pointy haired
bosses has almost immediately begun playing games with the version numbers,
product names, etc, and dropped the focus on quality, performance, bug fixes,
etc.  I don't expect that from the postgresql community, but I find discussion
on the mailing lists about using a "wow, 10.x.x release! how amazing" marketing
line rather crass.  I doubt many people in the tech industry generally feel all
that differently about it.  I've never worked with a programmer or DBA who was
impressed with these kinds of version number bumps.

I fully agree mine is a cynical point of view.

My main concern is that a commitment to never, ever break backwards
compatibility is a commitment to obsolescence.  It therefore makes sense to
reserve room in the numbering scheme to be clear and honest about when
backwards compatibility has been broken.  The major number is the normal
place to do that.

Just my .2 cents.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-13 Thread David G. Johnston
On Fri, May 13, 2016 at 7:32 PM, Mark Dilger 
wrote:

>
> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people,
> and
> software quality will go down from now on."
>

​Tom brought up my own thoughts on the rest - but, really, this is a
cynical way of looking at things.  At least insofar as whether marketing
has say over what exact version number is assigned to a release should, and
here likely does, have almost zero influence on the quality of the code
that went into said release.  This entire discussion and timeline is proof
of exactly that.  We have the option to market version 10.0.0 if we so
choose but during the entire past year -core hasn't cared whether the
release they are working toward is eventually numbered 9.6.0 or 10.0.0​ -
and I posit that nothing would have changed had it been decided a year ago
that we were going to release 10.0.0.

I'll accept that addressing the broader community's confusion regarding our
version numbering scheme is a problem worth addressing.  Therefore I
support moving to a simple "version.patch" system for next year's release.
Having accepted the importance of accepting the broader community's
opinions changing to 10 now after we've released beta1 would be
counter-productive.

Personally, having come in around the 8.2 release I didn't, and quite
honestly still don't, care why the decision was made to release 9.0 instead
of 8.5.  Mainly because the feature oriented decisions to increment seems
to be largely focused on the DBA - which is it not my primary concern.  For
me, the inclusion of window functions would have been enough to warrant a
major version bump - and CTEs as well.  Both of those went into 8.4.  So
not only is it getting harder to gain critical mass in a single release
(which is good - it means we are not settling for the easy stuff and are
properly breaking down harder features into small releaseables) but the
stuff we are keying on are likely of secondary importance to a large number
of users.

David J.


Re: [HACKERS] 10.0

2016-05-13 Thread Mark Dilger

> On May 13, 2016, at 5:49 PM, Josh berkus  wrote:
> 
> On 05/13/2016 05:22 PM, Mark Dilger wrote:
>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, 
>> and
>> software quality will go down from now on."
 
 I don't think this is about version number inflation, but actually more
 the opposite.  What you're calling the major number is really a marketing
 number.  There is not a technical distinction between major releases where
 we choose to bump the first number and those where we choose to bump the
 second.  It's all about marketing.  So to me, merging those numbers would
 be an anti-marketing move.  I think it's a good move: it would be more
 honest and transparent about what the numbers mean, not less so.
>> I find your argument persuasive if there is no possibility of ever needing
>> a major number to bump.  But if anything like what I described above could
>> someday happen, it seems the major.minor.micro format would come in
>> handy.  Perhaps the problem (from my perspective) is that the major number
>> has been used for purely marketing purposes in the past, and I've tried to
>> avert my eyes to that.  But going forward, my vote (worth less than half a
>> cent I'm sure) is to stop using it for marketing reasons.
> 
> Per a long discussion on -advocacy, nobody has any specific plans to do
> substantial breakage of backwards compatibility.  Theoretically we might
> someday want to change the on-disk format, but nobody has plans to do so
> in the immediate future.  How long should we hold out for that?  Until 9.27?
> 
> And I don't find dropping the "money" type to be substantial breakage.

If minor number bumps mean, "dump and restore is necessary, but client
programs are guaranteed to still work", then dropping the "money" type
is a different kind of action.  Maybe you don't think it matters much, but
for somebody who is using it in a client application, that matters.  Likewise,
somebody who has a struct in a client program that expects Oid to fit into
32 bits *needs* to go through their client programs if Oid ever gets changed
to 64 bit.  (Pigs will probably fly first, but just for instance.)

I'm not advocating any of these changes today.  I just think they are different
kinds of changes from adding new functions while leaving all old functions
in tact.  As cool as parallel query is (and I'd happily buy Robert or Amit a
beer) it doesn't break any functionality in client applications that ignore it,
so far as I can see.  Using parallel query as a motivation for increasing the
major number stems from a marketing instinct, not from sound engineering
practices.

Now that I've said that, I'll sit back and wait for the REL10_0_DEVEL
branch to appear in the repo.

mark





-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-13 Thread David G. Johnston
On Fri, May 13, 2016 at 6:44 PM, Michael Banck  wrote:

> On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> > The underlying premise, for me, of choosing .4 or .5  was that presently
> we
> > discontinue support after 5 years/releases.  A new .0 would come out just
> > as we discontinue the previous .0
>
> Well maybe the 5 year support cycle would be nice to encode, but how is
> .0 different from .1 then?  You make sound like .0 would be similar to
> Ubuntu's LTS which is not the case, unless you want to propose that only
> .0 releases get 5 years and not the in-betweens? That'd be a shame.
>

​The opinion seems to be that major.0 is some kind of magic incantation in
the broader world of users...so its basically "since the last time we
incremented major this is what we've done - 80% of which is new to you only
if you've lived under a rock for the past four years".

David J.
​


Re: [HACKERS] 10.0

2016-05-13 Thread Josh berkus
On 05/13/2016 05:22 PM, Mark Dilger wrote:
>>> >> Any project that starts inflating its numbering scheme sends a message to
>>> >> users of the form, "hey, we've just been taken over by marketing people, 
>>> >> and
>>> >> software quality will go down from now on."
>> > 
>> > I don't think this is about version number inflation, but actually more
>> > the opposite.  What you're calling the major number is really a marketing
>> > number.  There is not a technical distinction between major releases where
>> > we choose to bump the first number and those where we choose to bump the
>> > second.  It's all about marketing.  So to me, merging those numbers would
>> > be an anti-marketing move.  I think it's a good move: it would be more
>> > honest and transparent about what the numbers mean, not less so.
> I find your argument persuasive if there is no possibility of ever needing
> a major number to bump.  But if anything like what I described above could
> someday happen, it seems the major.minor.micro format would come in
> handy.  Perhaps the problem (from my perspective) is that the major number
> has been used for purely marketing purposes in the past, and I've tried to
> avert my eyes to that.  But going forward, my vote (worth less than half a
> cent I'm sure) is to stop using it for marketing reasons.

Per a long discussion on -advocacy, nobody has any specific plans to do
substantial breakage of backwards compatibility.  Theoretically we might
someday want to change the on-disk format, but nobody has plans to do so
in the immediate future.  How long should we hold out for that?  Until 9.27?

And I don't find dropping the "money" type to be substantial breakage.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-13 Thread Mark Dilger

> On May 13, 2016, at 5:00 PM, Tom Lane  wrote:
> 
> Mark Dilger  writes:
>> A major number change should indicate that something even bigger than on-disk
>> compatibility has changed, such as a change that precludes even a dump and
>> restore from working, or that breaks network communication protocols, etc.
> 
> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).  I can't imagine that we'd ever intentionally break
> dump/restore compatibility.  While we have changed the network protocol,
> and likely will again, we kept on supporting the old protocol alongside,
> and almost certainly would do so again.  There are too many compatibility
> constraints that we have to meet in order to be a usable database at all,
> so we're never going to just blow it up and start over.

Well, those are just examples.  Other candidate examples would be dropping
datatypes such as 'money' that were maybe not a good idea to begin with,
or somehow ditching the 'timestamp' vs. 'timestamptz' distinction, or 
changing to 64-bit Oids, such that software that interacts with postgresql
has to change accordingly.  Another such idea would be supporting 64-bit
varlena lengths and dropping large object support.  Another would be
dropping support for older communication protocols whose presence in the
server out of the box makes the server a security vulnerability.  (I am not
asserting the presence of such vulnerabilities, but just speculating on the
possibility that such vulnerabilities might be discovered in the future that
make it useful to ditch older, insecure protocols.)

I suspect other folks could add lots of other stuff to this list.


>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, and
>> software quality will go down from now on."
> 
> I don't think this is about version number inflation, but actually more
> the opposite.  What you're calling the major number is really a marketing
> number.  There is not a technical distinction between major releases where
> we choose to bump the first number and those where we choose to bump the
> second.  It's all about marketing.  So to me, merging those numbers would
> be an anti-marketing move.  I think it's a good move: it would be more
> honest and transparent about what the numbers mean, not less so.

I find your argument persuasive if there is no possibility of ever needing
a major number to bump.  But if anything like what I described above could
someday happen, it seems the major.minor.micro format would come in
handy.  Perhaps the problem (from my perspective) is that the major number
has been used for purely marketing purposes in the past, and I've tried to
avert my eyes to that.  But going forward, my vote (worth less than half a
cent I'm sure) is to stop using it for marketing reasons.

mark



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] 10.0

2016-05-13 Thread Tom Lane
Mark Dilger  writes:
> A major number change should indicate that something even bigger than on-disk
> compatibility has changed, such as a change that precludes even a dump and
> restore from working, or that breaks network communication protocols, etc.

If that were the standard, we'd never have bumped the major version at
all, and would still be on 4.something (or whatever Berkeley was using
when they tossed it over the wall; I'm not too clear on whether there was
ever a 5.x release).  I can't imagine that we'd ever intentionally break
dump/restore compatibility.  While we have changed the network protocol,
and likely will again, we kept on supporting the old protocol alongside,
and almost certainly would do so again.  There are too many compatibility
constraints that we have to meet in order to be a usable database at all,
so we're never going to just blow it up and start over.

> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people, and
> software quality will go down from now on."

I don't think this is about version number inflation, but actually more
the opposite.  What you're calling the major number is really a marketing
number.  There is not a technical distinction between major releases where
we choose to bump the first number and those where we choose to bump the
second.  It's all about marketing.  So to me, merging those numbers would
be an anti-marketing move.  I think it's a good move: it would be more
honest and transparent about what the numbers mean, not less so.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


  1   2   >