Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAZow-00036M-R8 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Nov 2017 11:07:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1eAZow-0006nK-6A for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Nov 2017 11:07:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eAZov-0006n0-Hh for pgsql-hackers@postgresql.org; Fri, 03 Nov 2017 11:07:29 +0000 Received: from tamriel.snowman.net ([2001:470:e38f::11]) by makus.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eAZos-00022l-3r for pgsql-hackers@postgresql.org; Fri, 03 Nov 2017 11:07:28 +0000 Received: by tamriel.snowman.net (Postfix, from userid 1000) id C7D995F795; Fri, 3 Nov 2017 07:07:25 -0400 (EDT) Date: Fri, 3 Nov 2017 07:07:25 -0400 From: Stephen Frost To: Robert Haas Cc: Simon Riggs , Peter Geoghegan , Michael Paquier , PostgreSQL-development Subject: Re: MERGE SQL Statement for PG11 Message-ID: <20171103110725.GT4628@tamriel.snowman.net> References: <20171030185511.GJ4628@tamriel.snowman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+N+oEm2pdbsErCTe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org --+N+oEm2pdbsErCTe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Robert Haas (robertmhaas@gmail.com) wrote: > On Fri, Nov 3, 2017 at 1:05 PM, Simon Riggs wrote: > > We seem to have a few options for PG11 > > > > 1. Do nothing, we reject MERGE > > > > 2. Implement MERGE for unique index situations only, attempting to > > avoid errors (Simon OP) > > > > 3. Implement MERGE, but without attempting to avoid concurrent ERRORs (= Peter) > > > > 4. Implement MERGE, while attempting to avoid concurrent ERRORs in > > cases where that is possible. > > > > Stephen, Robert, please say which option you now believe we should pick. >=20 > I think Peter has made a good case for #3, so I lean toward that > option. I think #4 is too much of a non-obvious behavior difference > between the cases where we can avoid those errors and the cases where > we can't, and I don't see where #2 can go in the future other than #4. Agreed. Thanks! Stephen --+N+oEm2pdbsErCTe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJZ/E3tAAoJEO1sijiDR2RVqvMQAKmFaFCBc8V7O0zHb3x/rNzW AT0++AmygGFZCMPm2fUZ7UHgOUbJQ5gzn+OyrblsWKH9yEaMd8ux9GDLZU2SRhru Aznh8W/ImqilD/olZmE4MXbRVW4ZSdRFKVoZw0JwXK+5aOk0MGHALqDlSik4JBu7 DgtHNN623gR36XVWYrCQyuTP4lZk5YMgsO2Em2u2C7DNnm5OuWm6mGFyK34GezJO TI3AdJlMex5PIvkPACnIPpo9wINX/YZysIT0ZpCwPS5Fry4SlruAzMfgXK7JA1KX 9yaRwEQ7WZhIAnLCPFztXAi3WDf6FBezXfWyep6Jhj3xiTnt/aNN4P9FIw4V07CD v0WhEkBjalUwSLrqK4QvfWPBaBYZZohIt92be3CWN/dPQgpD8RWqMHl6l2Pk8xvV ecVdIYOFBL0fKgyB8AB/yCixvMxwoMijrRtd2EaTS/Rx0Wy3W1i8A6Q4ezeQoygF ecacHfgJf36sJBdoFkY3Jye/Caxj7envWAYPc7Vr0IYGWgE9dh5563QaZIKutLOW KJ7nYiMa4d6tSls321rl33k2yHfSEO+hglb/2Re0wtzrbTAwONiTa+Mss1pE1ySQ lBeTdzz0HaNwFuOdbmXp0Gn6U75I/OKDcq+JBHr2Fry83+rUb/mHAWR1/UCQbfcc BEXm1Y8cUHKXlUd5qtTT =wLCZ -----END PGP SIGNATURE----- --+N+oEm2pdbsErCTe--