> On 27 Feb 2018, at 11:10, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 27 Feb 2018, at 05:25, Tom Lane wrote:
>>> BTW, I noticed while doing this that the adjacent "funny_dup17"
>>> trigger is dead code, and has been since commit 1547ee01 of
>>> 1999-09-29. I'm inclined to rip it out
Daniel Gustafsson writes:
>> On 27 Feb 2018, at 05:25, Tom Lane wrote:
>> BTW, I noticed while doing this that the adjacent "funny_dup17"
>> trigger is dead code, and has been since commit 1547ee01 of
>> 1999-09-29. I'm inclined to rip it out, because anyone looking
>> at regress.c would natural
Thanks Tom.
On Tue, Feb 27, 2018 at 2:55 AM, Tom Lane wrote:
> I wrote:
> > I wonder whether it is worth creating a C trigger function
> > (probably in regress.c) specifically to exercise this situation.
>
> Actually, that doesn't seem too bad at all. I propose applying
> and back-patching the
> On 27 Feb 2018, at 05:25, Tom Lane wrote:
>
> I wrote:
>> I wonder whether it is worth creating a C trigger function
>> (probably in regress.c) specifically to exercise this situation.
>
> Actually, that doesn't seem too bad at all. I propose applying
> and back-patching the attached.
LGTM
I wrote:
> I wonder whether it is worth creating a C trigger function
> (probably in regress.c) specifically to exercise this situation.
Actually, that doesn't seem too bad at all. I propose applying
and back-patching the attached.
BTW, I noticed while doing this that the adjacent "funny_dup17"
Rushabh Lathia writes:
> In ExecBRUpdateTriggers(), we need to add a check that if trigtuple is same
> as newtuple, then we don't require to free the trigtuple.
Hm. Seems like this is a very old bug: it's always been legal for a
trigger to return the "old" tuple if it felt like it, even if plpgs
