Date: Wed, 19 Jan 2022 06:25:58 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Langote <amitlangote09@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>,
	Ibrar Ahmed <ibrar.ahmad@gmail.com>,
	Arne Roland <A.Roland@index.de>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	Masahiko Sawada <sawada.mshk@gmail.com>,
	Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Rahila Syed <rahilasyed90@gmail.com>,
	Tomas Vondra <tomas.vondra@2ndquadrant.com>
Subject: Re: a misbehavior of partition row movement (?)
Message-ID: <202201190925.rrnex5zf56vz@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CA+HiwqFuAi7zCEC_7dhOLoEQ_HTq4DOyp9-NKzfZVNRdFHSs3w@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202201190925.rrnex5zf56vz%40alvherre.pgsql>
Precedence: bulk

On 2022-Jan-19, Amit Langote wrote:

> BTW, your tweaks patch added this:
> 
> + *     *inserted_tuple is the tuple that's effectively inserted;
> + *     *inserted_destrel is the relation where it was inserted.
> + *     These are only set on success.  FIXME -- see what happens on
> the "do nothing" cases.
> 
> If by "do nothing cases" you mean INSERT ON CONFLICT ... DO NOTHING,
> then I don't think it matters, because the caller in that case would
> be ExecModifyTable() which doesn't care about inserted_tuple and
> inserted_destrel.

No, I meant a FOR EACH ROW trigger that does RETURN NULL to "abort" the
insertion.  IIRC in non-partitioned cases it is possibly to break
referential integrity by using those.  What I was wondering is whether
you can make this new code crash.

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"I can see support will not be a problem.  10 out of 10."    (Simon Wittber)
      (http://archives.postgresql.org/pgsql-general/2004-12/msg00159.php)