Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gJUen-0004pH-7N for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Nov 2018 02:30:25 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gJUel-0003yz-D4 for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Nov 2018 02:30:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gJUej-0003y4-Rn for pgsql-hackers@lists.postgresql.org; Mon, 05 Nov 2018 02:30:23 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1gJUeh-0004Io-HP for pgsql-hackers@postgresql.org; Mon, 05 Nov 2018 02:30:20 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id CDA8B21D1F; Sun, 4 Nov 2018 21:30:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 04 Nov 2018 21:30:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paquier.xyz; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=grTa9NEi4WOW+RlHDCVUUtKVHHr TQ+hsx9/FA6SnM5w=; b=XKbnwRe0bNyFquApvuD83sIP0IPZynpFrZ2rr21Wjmf i1GCkvVnrj/T/OYBOlPQQap1FzfbTk7BOTNe25C2mwSZypZpXreHOoSJutHIsgmV g35MNrVTzedU0FSa3apiw5MOzkVZG+Dvl0pm4LACQ4LPghR8XcjpyZtLCcUvVmbR AjqGy8qBqxLkkbjcGz3mTlylyfcgOeP82xs6W+/Nq+PF4dfvZwO+Z1osOZZsLNGA 0kqCwnn/7OFCJCBTl2TQ/I3TJ0rWTKBzOCfsIV1juRSqegUol7hDzxjnib36M9+L nMuCMVygz9PkPx5VOhYEkYcj3vpYRNlhiTjWMFYTZPw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=grTa9N Ei4WOW+RlHDCVUUtKVHHrTQ+hsx9/FA6SnM5w=; b=VNbqLhfMaq/RNO+eP8jDCJ LbCVZT8XSPtqw/OKvz7DdvBYhngd2wrbRFhHofDth82UlgbvW3b74HWoKMyCdsmd YNdn8opAmneG6EPPcJvs33YT1NsPUqPwNZTsxBqtqsq1Oqj00szI2ug2KBSm43ap 7fRn1SWg9wJ1G/APbMvHdbFo7Efw2PDglvMOi8cg32D7nww4S2zfim/J/0qkdXxr O7UHzQC4nDcT4PUA2EpOa82ccGlUMlUKxxt5BS0sTFxnSOVP+NvwHICFiXnqEjRT GQamqTwhWkK0FzdXdu9iuMND5tfGzLh9/ISHxmDB85Q7cHfRA7m4K97nCiwspg6g == X-ME-Sender: X-ME-Proxy: Received: from paquier.xyz (c137162.net61215.cablenet.ne.jp [61.215.137.162]) by mail.messagingengine.com (Postfix) with ESMTPA id 57F6E102E0; Sun, 4 Nov 2018 21:30:16 -0500 (EST) Date: Mon, 5 Nov 2018 11:30:13 +0900 From: Michael Paquier To: Stephen Frost Cc: Tom Lane , Surafel Temesgen , PostgreSQL Hackers Subject: Re: pg_dump multi VALUES INSERT Message-ID: <20181105023013.GD1718@paquier.xyz> References: <27171.1539719339@sss.pgh.pa.us> <20181017190528.GD4184@tamriel.snowman.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xB0nW4MQa6jZONgY" Content-Disposition: inline In-Reply-To: <20181017190528.GD4184@tamriel.snowman.net> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --xB0nW4MQa6jZONgY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 17, 2018 at 03:05:28PM -0400, Stephen Frost wrote: > The point of it is that it makes loading into other RDBMS faster. Yes, > it has many of the same issues as our COPY does, but we support it > because it's much faster. The same is true here, just for other > databases, so I'm +1 on the general idea. Well, the patch author has mentioned that he cares about also being able to detect errors when processing the dump, which multi inserts make that easier to check for. However, even if you specify --data-only you still need to worry about the first SET commands ahead, which requires manual handling of the dump... I am honestly not convinced that it is worth complicating pg_dump for that, as there is no guarantee either that the DDLs generated by pg_dump will be compatible with what other systems expect. This kind of compatibility for fetch and reload can also be kind of tricky with portability issues, so I'd rather let this stuff being handled correctly by other tools like pgloader or others rather than expecting to get this stuff half-baked within Postgres core tools. -- Michael --xB0nW4MQa6jZONgY Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlvfqzUACgkQnvQgOdby QH0zeQ//f4BH6UtDvK9nUNspt4/XHWOoalIV/5ICwSvqNjiSqwejKKZkBf5XnLDr dUVv5hLzXGDtp+2w9P25dPU+uAQ0msMqaARlrrv4ieWDqmd9/3kVuNGeFSwzjKKG ldf26QX6/jlVfcJy8pOFTTeD5fn6GRJ615zNiqOZbtMV9iiukzV3NWfrWHPzqYss M+NehWTDL5zU8vGw8v/3ccVhdCUtDUjLN2TT5ebei1YNoS8YszExqrqR3OUuMW6q gDRjAH2OwBK2W0ngoBuEEyjNWkUHqVK+puseL9LzzhANrxxE/X+kqWmdTfj0SrKd cvG0WuiD4p4WjRyGPeScCWpgpSxgnHLbDrfteSHZTYk2GHUKmAXPcBgvu2b3F4fX n2lESeqJBz3dtH5f4VDFc/vNIObbH4P4Ko7sVD8PFNWSQLcRC7d5k5FU7q8bW3O9 SFO1z4i30AuRKBCuqTi/VFJ49oOev+XS8oa3rXfwF0vfPq0pbr7vh8mchgHliEaC OeMr0XnvISDNbZogkqrECPVBfkLBHzA9/7mt+hGF4zP7T0kCr6DzdQ+2oV4Iv0JE iNW2yeiYZNW76ip//IXZ386Yxv/EZGW0qaVkhD8qrUr9pWtbo9X8bRmbmSyGzPfV Ic43sI/IZi1Dq9TnYGQa3KYNwWHGCVa1nmdSbeL20OjP5Y3dY7U= =MMlw -----END PGP SIGNATURE----- --xB0nW4MQa6jZONgY--