[HACKERS] 10.0: Logical replication doesn't execute BEFORE UPDATE OF trigger

Hi hackers, I've found something that looks like a bug. Steps to reproduce -- There are 3 instances of PostgreSQL 10.0 - inst1, inst2 and inst3. There is a table `test` on every instance: ``` CREATE TABLE test(k TEXT PRIMARY KEY, v TEXT); ``` Both inst1 and inst2 have `allpub`

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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.

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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,

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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,

Re: [HACKERS] 10.0

> 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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

> 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

Re: [HACKERS] 10.0

> 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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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 >

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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,

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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.

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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.

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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,

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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 >

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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,

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

-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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

+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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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 >

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

> 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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

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

Re: [HACKERS] 10.0

> 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

  1   2   >