Re: BUG #19370: PG18 returns incorrect array slice results when slice bounds depend on another array expression
| От | Tom Lane |
|---|---|
| Тема | Re: BUG #19370: PG18 returns incorrect array slice results when slice bounds depend on another array expression |
| Дата | |
| Msg-id | 1606057.1767724523@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: BUG #19370: PG18 returns incorrect array slice results when slice bounds depend on another array expression (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: BUG #19370: PG18 returns incorrect array slice results when slice bounds depend on another array expression
Re: BUG #19370: PG18 returns incorrect array slice results when slice bounds depend on another array expression |
| Список | pgsql-bugs |
Andres Freund <andres@anarazel.de> writes:
> On 2026-01-06 11:40:01 -0500, Tom Lane wrote:
>> We could either generalize EEOP_PARAM_SET to include an explicit
>> specification of the source value's address
> That's pretty trivial, see attached. I don't quite understand why I didn't go
> that way immediately...
Yeah, that looks about right.
> At the very least we need to create a simplified testcase for the bug at hand.
Yup, the sudoku example is fun but it seems inappropriate as a test
case.
>> or insert some kind of LOAD operation to copy the computed value into
>> state->resvalue/resnull. I don't see anything that looks like that today,
>> though.
> Hm, wouldn't that have exactly the same issues as we have today anyway?
Indeed ... -ENOCAFFEINE
regards, tom lane
В списке pgsql-bugs по дате отправления: