Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMDA7-0003NM-I0 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2020 16:02:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jMDA6-0006sC-G1 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2020 16:02:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jMDA6-0006s5-8n for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2020 16:02:46 +0000 Received: from mail-qv1-xf42.google.com ([2607:f8b0:4864:20::f42]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jMDA3-0000ub-Ub for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2020 16:02:45 +0000 Received: by mail-qv1-xf42.google.com with SMTP id o15so1358818qvl.3 for ; Wed, 08 Apr 2020 09:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=BiaSBFPGwNLCmJHTEzIF/JNQjKWxJa+jCF73ReiaY0o=; b=vMYKvqhdQVqpaT+5e4tblpDfqUWEt8zvqW+ILnUaoT2CZLeANS2x9LTRiO12vqZhvN E0zFBUTXr0bmUxvlZFgek+cD/jJvlfZH6NVygq0e2v7kgJbpTXm2RPgsxco3NCY3NBRT zXw4JrLF40tGL2kkTovsj75ZLtaKAbGCR23HnvxBLCMLVyGVlwjWChoJNCBnkwu2qlcO PYbUB9g+Kroi7UR3ByQYbMr2oiUTp8Tj87x8FPoZSTG6wIOLe9h4SNcGNlqNfZi5szVa JfMyq/HDyFmAKAHLOmpC+izTTlIWJHbjKAI9jfeErbTsndDpnZxokvS3SmfDy1UMBYpc oB4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=BiaSBFPGwNLCmJHTEzIF/JNQjKWxJa+jCF73ReiaY0o=; b=kqbakIhTFQaNFhMyvjMpcUb8xMNvbIyb/z+vQMQY6DGbfGHLbZANpjApR7Do3QVYrm xEWI9w5QRPx9T2kJLHuCGgmSMCd8Mbvcw9haW2yQbWiI0od1fKn0xVBCJjkqCsCIlGTp PEz7dHtu9GnD+mqiUYGC0zUBWebi6om2WjVomzz9Vx8kJEH7j7BQScdiWpy+FuMWVKJf ASKWNKTXt7GjfN+pL7GNzc+p79V90P1d9jZk5KVmv1IlyCYiZG+d+C3GecsayX5bfBHb N3KBL6G8DlykhXZhX5LWBuGDTGu3punQZOXo1GXhEnt/U3CjYdJ7qd6KJRyFLmiMZrym ntCA== X-Gm-Message-State: AGi0PuZf4eDiT3ZhbjTSiT5y5oI5NR2KPMQ29XE/BZQssxaXZ1MPino9 6CNYivBqk4mG+U3f3vU0V6eTniw+vKE+IYDSrZ/1kxEV1sEG46Rp34E5/hBa9qOh5fAL5AvSYP6 bRlQlxu7c2Ho0qg6ChXAgwkam8dVFA4ne9F/ksHsz8FllI2TwIi57msvTXPcqniK9WN5J9/wvh3 8o646HfJdYgo/EQQll X-Google-Smtp-Source: APiQypLbNRLinmCJzVtd6p2j+uERzLSDMmf1gKKRtJWp0u1FxLtV26vG5MPiB2quVK6idx1/eNqPkw== X-Received: by 2002:a05:6214:118a:: with SMTP id t10mr298576qvv.9.1586361762585; Wed, 08 Apr 2020 09:02:42 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id h138sm19379258qke.86.2020.04.08.09.02.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Apr 2020 09:02:42 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id BEA22300AAD; Wed, 8 Apr 2020 12:02:39 -0400 (-04) Date: Wed, 8 Apr 2020 12:02:39 -0400 From: Alvaro Herrera To: Justin Pryzby Cc: pgsql-hackers@lists.postgresql.org Subject: Re: DETACH PARTITION and FOR EACH ROW triggers on partitioned tables Message-ID: <20200408160239.GA13987@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200408152412.GZ2228@telsasoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Apr-08, Justin Pryzby wrote: > This seems to be a bug in master, v12, and (probably) v11, where "FOR EACH FOR" > was first allowed on partition tables (86f575948). > > I thought this would work like partitioned indexes (8b08f7d48), where detaching > a partition makes its index non-inherited, and attaching a partition marks a > pre-existing, matching partition as inherited rather than creating a new one. Hmm. Let's agree to what behavior we want, and then we implement that. It seems to me there are two choices: 1. on detach, keep the trigger but make it independent of the trigger on parent. (This requires that the trigger is made dependent on the trigger on parent, if the table is attached as partition again; otherwise you'd end up with multiple copies of the trigger if you detach/attach multiple times). 2. on detach, remove the trigger from the partition. I think (2) is easier to implement, but (1) is the more convenient behavior. (The current behavior is obviously a bug.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services