From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Arne Roland <A(dot)Roland(at)index(dot)de>, vignesh C <vignesh21(at)gmail(dot)com>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Rename of triggers for partitioned tables |
Date: | 2021-07-26 17:14:20 |
Message-ID: | 202107261714.kuzrvstzrufh@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-Jul-25, Tom Lane wrote:
> Perhaps there's no actual bug there, but it's still horrible coding.
> For one thing, the implication that found could be negative is extremely
> confusing to readers. A boolean might be better. However, I wonder why
> you bothered with a flag in the first place. The usual convention if
> we know there can be only one match is to just not write a loop at all,
> with a suitable comment, like this pre-existing example elsewhere in
> trigger.c:
>
> /* There should be at most one matching tuple */
> if (HeapTupleIsValid(tuple = systable_getnext(tgscan)))
>
> If you're not quite convinced there can be only one match, then it
> still shouldn't be an Assert --- a real test-and-elog would be better.
I agree that coding there was dubious. I've removed the flag and assert.
Arne complained that there should be a unique constraint on (tgrelid,
tgparentid) which would sidestep the need for this to be a loop. I
don't think it's really necessary, and I'm not sure how to create a
system index WHERE tgparentid <> 0.
--
Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/
"Saca el libro que tu religión considere como el indicado para encontrar la
oración que traiga paz a tu alma. Luego rebootea el computador
y ve si funciona" (Carlos Duclós)
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-07-26 17:14:47 | Re: Avoiding data loss with synchronous replication |
Previous Message | Robert Haas | 2021-07-26 17:11:31 | Re: when the startup process doesn't (logging startup delays) |