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

2019-09-24 Thread Andres Freund
Hi, On 2019-09-22 14:24:36 -0400, Tom Lane wrote: > "Tsunakawa, Takayuki" 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

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

2019-09-23 Thread Tsunakawa, Takayuki
From: Tom Lane [mailto:t...@sss.pgh.pa.us] > 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,

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

2019-09-22 Thread Tom Lane
"Tsunakawa, Takayuki" 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

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

2019-09-12 Thread Tsunakawa, Takayuki
Hello, 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? BTW, I thought that in PostgreSQL coding convention, local variables should be defined at the top of blocks,