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 1f8nJr-0007mp-Mb for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Apr 2018 13:40:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1f8nJq-0006jo-3v for pgsql-hackers@arkaria.postgresql.org; Wed, 18 Apr 2018 13:40:18 +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.89) (envelope-from ) id 1f8nJp-0006jQ-Pd for pgsql-hackers@lists.postgresql.org; Wed, 18 Apr 2018 13:40:17 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1f8nJi-0001Cn-Cz for pgsql-hackers@postgresql.org; Wed, 18 Apr 2018 13:40:16 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 3B0D512E2; Wed, 18 Apr 2018 09:40:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 18 Apr 2018 09:40:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=QdTt7fpk2ZjtyMIwu jLOrGCjLJs0E1y3HvxlkgM0JzM=; b=fNrKAER3c/TsLQVkCA+VfyC37olumTriL u1acviXIUUY9HjNXWFtJL87QozhUzEvbzE78FbagDQljunz81ujCOegjEWq9lyjX mTGonJDufM5Px4ontlYxDLWFPDutp9SyNTlCwiAaeCMfFFR1ueWMENqcV2GgAPrx fznKYwcrQuUfo07MZgMpetPlTq0pY1kObsmGKsnZEOMiTx7SjpYC6Osp9QwJHZRf VNcA7kWczq7qA13+DHpXnVOsHvB594TM+qqxss2n59obwYF6Qa/UArlnRVD34PsR H+Y7oDVDuzrEjxXDbwWzzBUvKtDfIbbnpL469wLkUNMkoOch+YiCQ== X-ME-Sender: Received: from alvin.alvh.no-ip.org (unknown [179.56.29.253]) by mail.messagingengine.com (Postfix) with ESMTPA id 7C7D6E43EC; Wed, 18 Apr 2018 09:40:08 -0400 (EDT) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id 3009F60D; Wed, 18 Apr 2018 10:40:07 -0300 (-03) Date: Wed, 18 Apr 2018 10:40:07 -0300 From: Alvaro Herrera To: Amit Langote Cc: Pavan Deolasee , Etsuro Fujita , Andres Freund , Pg Hackers , Peter Geoghegan Subject: Re: ON CONFLICT DO UPDATE for partitioned tables Message-ID: <20180418134007.n7vbkwww4e22sg6k@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote wrote: > On 2018/04/18 0:04, Alvaro Herrera wrote: > > Amit Langote wrote: > > > >> I just confirmed my hunch that this wouldn't somehow do the right thing > >> when the OID system column is involved. Like this case: > > > > This looks too big a patch to pursue now. I'm inclined to just remove > > the equalTupdesc changes. > > OK. Here is the patch that removes equalTupdesc optimization. Hmm. If we modify (during pg12, of course -- not now) partition tables that are created identical to their parent table so that they share the pg_type row, this would become useful. Unless there a reason why that change is completely unworkable, I'd just leave it there. (I claim that it works like that only because it used to work like that, not because it's impossible to make work the other way.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services