From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [bug fix??] Fishy code in tts_cirtual_copyslot() |
Date: | 2019-09-22 18:24:36 |
Message-ID: | 19783.1569176676@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> writes:
> In the following code in execTuples.c, shouldn' srcdesc point to the source slot's tuple descriptor? The attached fix passes make check. What kind of failure could this cause?
Yeah, sure looks like a typo to me too.
I temporarily changed the Assert to be "==" rather than "<=", and
it still passed check-world, so evidently we are not testing any
cases where the descriptors are of different lengths. This explains
the lack of symptoms. It's still a bug though, so pushed.
> BTW, I thought that in PostgreSQL coding convention, local variables should be defined at the top of blocks, but this function writes "for (int natts;".
Yeah, we've agreed to join the 21st century to the extent of allowing
local for-loop variables.
Thanks for the report!
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-09-22 20:36:28 | Re: JSONPATH documentation |
Previous Message | Jeff Janes | 2019-09-22 18:18:04 | JSONPATH documentation |