Re: [HACKERS] MERGE SQL Statement for PG11

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)2ndquadrant(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Date: 2018-01-29 16:06:12
Message-ID: 3200.1517241972@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On 29 January 2018 at 15:07, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> An argument could be made that this patch is already too late for PG
>> 11, because it's a major feature that was not submitted in relatively
>> complete form before the beginning of the penultimate CommitFest.

> Overall, I'm following the style of development process you have
> yourself used a number of times now. Waiting for mega-patches to be
> complete is not as useful as phased development.

An important part of that style is starting at an appropriate time in the
release cycle. As things stand, you are proposing to commit an unfinished
feature to v11, and then we have to see if the missing parts show up on
time (ie before 1 March) and with adequate quality. Otherwise we'll be
having a debate on whether to revert the feature or not ... and if it
comes to that, my vote will be for reverting.

I'd be much happier about committing this with some essential parts
missing if it were done at the start of a devel cycle rather than near
the end.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2018-01-29 16:06:27 Re: Built-in connection pooling
Previous Message Ildus Kurbangaliev 2018-01-29 16:04:03 Re: [HACKERS] Custom compression methods