Re: json_query conditional wrapper bug
От | Peter Eisentraut |
---|---|
Тема | Re: json_query conditional wrapper bug |
Дата | |
Msg-id | 6de6d56b-d2c2-4a4c-bb44-bbeff1ed3aef@eisentraut.org обсуждение исходный текст |
Ответ на | Re: json_query conditional wrapper bug (Amit Langote <amitlangote09@gmail.com>) |
Ответы |
Re: json_query conditional wrapper bug
|
Список | pgsql-hackers |
On 11.09.24 13:25, Amit Langote wrote: > On Wed, Sep 11, 2024 at 6:57 PM Peter Eisentraut <peter@eisentraut.org> wrote: >> On 11.09.24 09:51, Amit Langote wrote: >>>>> I've updated your patch to include updated test outputs and a nearby >>>>> code comment expanded. Do you intend to commit it or do you prefer >>>>> that I do? >>>> >>>> This change looks unrelated: >>>> >>>> -ERROR: new row for relation "test_jsonb_constraints" violates check >>>> constraint "test_jsonb_constraint4" >>>> +ERROR: new row for relation "test_jsonb_constraints" violates check >>>> constraint "test_jsonb_constraint5" >>>> >>>> Is this some randomness in the way these constraints are evaluated? >>> >>> The result of JSON_QUERY() in the CHECK constraint changes, so the >>> constraint that previously failed now succeeds after this change, >>> because the comparison looked like this before and after: >>> >>> -- before >>> postgres=# select jsonb '[10]' < jsonb '[10]'; >>> ?column? >>> ---------- >>> f >>> (1 row) >>> >>> -- after >>> postgres=# select jsonb '10' < jsonb '[10]'; >>> ?column? >>> ---------- >>> t >>> (1 row) >>> >>> That causes the next constraint to be evaluated and its failure >>> reported instead. >>> >>> In the attached, I've adjusted the constraint for the test case to be >>> a bit more relevant and removed a nearby somewhat redundant test, >>> mainly because its output changes after the adjustment. >> >> Ok, that looks good. Good that we could clear that up a bit. > > Thanks for checking. Would you like me to commit it? Please do.
В списке pgsql-hackers по дате отправления: