Re: a misbehavior of partition row movement (?)
От | Alvaro Herrera |
---|---|
Тема | Re: a misbehavior of partition row movement (?) |
Дата | |
Msg-id | 202201190925.rrnex5zf56vz@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: a misbehavior of partition row movement (?) (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: a misbehavior of partition row movement (?)
|
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: