Re: [HACKERS] MERGE SQL Statement for PG11

On 29 January 2018 at 16:06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I agree with all of the above.

In terms of timing of commits, I have marked the patch Ready For
Committer. To me that signifies that it is ready for review by a
Committer prior to commit.

In case of doubt, I would not even suggest committing this if it had
any concurrency issues. That would be clearly unacceptable.

The only discussion would be about the word "unfinished". I'm not
clear why this patch, which has current caveats all clearly indicated
in the docs, differs substantially from other projects that have
committed their work ahead of having everything everybody wants, such
as replication, materialized views, parallel query, partitioning,
logical decoding etc.. All of those features had caveats in the first
release in which they were included and many of them were committed
prior to the last CF. We are working now to remove those caveats. Why
is this different? It shouldn't be. If unfinished means it has caveats
that is different to unfinished meaning crappy, risky, contentious
etc..

Anyway, reviews welcome, but few people know anything about
targetlists and column handling.

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