Re: [bug fix??] Fishy code in tts_cirtual_copyslot()

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

In response to

Responses

Browse pgsql-hackers by date

  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