Re: remaining sql/json patches - Mailing list pgsql-hackers

From Nikita Malakhov
Subject Re: remaining sql/json patches
Date
Msg-id CAN-LCVPv=P+UemvAUjXSeD4WrNhCDJZAcY5TGdtyJy2_YbeX9Q@mail.gmail.com
Whole thread Raw
In response to Re: remaining sql/json patches  (jian he <jian.universality@gmail.com>)
Responses Re: remaining sql/json patches
List pgsql-hackers
Hi!

Amit, on previous email, patch #2 - I agree that it is not the best idea to introduce
new type of logic into the parser, so this logic could be moved to the executor,
or removed at all. What do you think of these options?

On Wed, Oct 18, 2023 at 5:19 AM jian he <jian.universality@gmail.com> wrote:
Hi.
based on v22.

I added some tests again json_value for the sake of coverager test.

A previous email thread mentioned needing to check *empty in ExecEvalJsonExpr.
since JSON_VALUE_OP, JSON_QUERY_OP, JSON_EXISTS_OP all need to have
*empty cases, So I refactored a little bit.
might be helpful. Maybe we can also refactor *error cases.

The following part is not easy to understand.
res = ExecPrepareJsonItemCoercion(jbv,
+  jsestate->item_jcstates,
+  &post_eval->jcstate);
+ if (post_eval->jcstate &&
+ post_eval->jcstate->coercion &&
+ (post_eval->jcstate->coercion->via_io ||
+ post_eval->jcstate->coercion->via_populate))


--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company

pgsql-hackers by date:

Previous
From: Daniele Varrazzo
Date:
Subject: Re: libpq async connection and multiple hosts
Next
From: Ashutosh Sharma
Date:
Subject: Should we represent temp files as unsigned long int instead of signed long int type?