From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | Ajin Cherian <itsajin(at)gmail(dot)com>, Zheng Li <zhengli10(at)gmail(dot)com>, li jie <ggysxcq(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, rajesh singarapu <rajesh(dot)rs0541(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Support logical replication of DDLs |
Date: | 2023-02-10 16:20:55 |
Message-ID: | CALDaNm2ck3c-UDx5QfzJgMDu9rzVa-tj+UGrMDLWBJ020_5wvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Thu, 9 Feb 2023 at 03:47, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> Hi Vignesh, thanks for addressing my v63-0002 review comments.
>
> I confirmed most of the changes. Below is a quick follow-up for the
> remaining ones.
>
> On Mon, Feb 6, 2023 at 10:32 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> >
> > On Mon, 6 Feb 2023 at 06:47, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > >
> ...
> > >
> > > 8.
> > > + value = findJsonbValueFromContainer(container, JB_FOBJECT, &key);
> > >
> > > Should the code be checking or asserting value is not NULL?
> > >
> > > (IIRC I asked this a long time ago - sorry if it was already answered)
> > >
> >
> > Yes, this was already answered by Zheng, quoting as "The null checking
> > for value is done in the upcoming call of expand_one_jsonb_element()."
> > in [1]
>
> Thanks for the info. I saw that Zheng-san only wrote it is handled in
> the “upcoming call of expand_one_jsonb_element”, but I don’t know if
> that is sufficient. For example, if the execution heads down the other
> path (expand_jsonb_array) with a NULL jsonarr then it going to crash,
> isn't it? So I still think some change may be needed here.
Added an Assert for this.
> > > 11.
> > > +/*
> > > + * Expand a JSON value as an operator name.
> > > + */
> > > +static void
> > > +expand_jsonval_operator(StringInfo buf, JsonbValue *jsonval)
> > >
> > > Should this function comment be more like the comment for
> > > expand_jsonval_dottedname by saying there can be an optional
> > > "schemaname"?
> >
> > Modified
>
> Is it really OK for the “objname" to be optional here (Yes, I know the
> code is currently implemented like it is OK, but I am doubtful)
>
> That would everything can be optional and the buf result might be
> nothing. It could also mean if the "schemaname" is provided but the
> "objname" is not, then the buf will have a trailing ".".
>
> It doesn't sound quite right to me.
I checked that we have specified operator names everywhere, so added
error handling for this case and modified the function header
accordingly.
> > > ~~~
> > >
> > > 12.
> > > +static bool
> > > +expand_jsonval_string(StringInfo buf, JsonbValue *jsonval)
> > > +{
> > > + if (jsonval->type == jbvString)
> > > + {
> > > + appendBinaryStringInfo(buf, jsonval->val.string.val,
> > > + jsonval->val.string.len);
> > > + }
> > > + else if (jsonval->type == jbvBinary)
> > > + {
> > > + json_trivalue present;
> > > +
> > > + present = find_bool_in_jsonbcontainer(jsonval->val.binary.data,
> > > + "present");
> > > +
> > > + /*
> > > + * If "present" is set to false, this element expands to empty;
> > > + * otherwise (either true or absent), fall through to expand "fmt".
> > > + */
> > > + if (present == tv_false)
> > > + return false;
> > > +
> > > + expand_fmt_recursive(jsonval->val.binary.data, buf);
> > > + }
> > > + else
> > > + return false;
> > > +
> > > + return true;
> > > +}
> > >
> > > I felt this could be simpler if there is a new 'expanded' variable
> > > because then you can have just a single return point instead of 3
> > > returns;
> > >
> > > If you choose to do this there is a minor tweak to the "fall through" comment.
> > >
> > > SUGGESTION
> > > expand_jsonval_string(StringInfo buf, JsonbValue *jsonval)
> > > {
> > > bool expanded = true;
> > >
> > > if (jsonval->type == jbvString)
> > > {
> > > appendBinaryStringInfo(buf, jsonval->val.string.val,
> > > jsonval->val.string.len);
> > > }
> > > else if (jsonval->type == jbvBinary)
> > > {
> > > json_trivalue present;
> > >
> > > present = find_bool_in_jsonbcontainer(jsonval->val.binary.data,
> > > "present");
> > >
> > > /*
> > > * If "present" is set to false, this element expands to empty;
> > > * otherwise (either true or absent), expand "fmt".
> > > */
> > > if (present == tv_false)
> > > expanded = false;
> > > else
> > > expand_fmt_recursive(jsonval->val.binary.data, buf);
> > > }
> > >
> > > return expanded;
> > > }
> >
> > I'm not sure if this change is required as this will introduce a new
> > variable and require it to be set, this variable should be set to
> > "expand = false" in else after else if also, instead I preferred the
> > existing code. I did not make any change for this unless you are
> > seeing some bigger optimization.
> >
>
> Sorry, I messed up the previous code suggestion. It should have said:
>
> SUGGESTION
> expand_jsonval_string(StringInfo buf, JsonbValue *jsonval)
> {
> bool expanded = false;
>
> if (jsonval->type == jbvString)
> {
> appendBinaryStringInfo(buf, jsonval->val.string.val,
> jsonval->val.string.len);
> expanded = true;
> }
> else if (jsonval->type == jbvBinary)
> {
> json_trivalue present;
> present =
> find_bool_in_jsonbcontainer(jsonval->val.binary.data, "present");
>
> /*
> * If "present" is set to false, this element expands to empty;
> * otherwise (either true or absent), expand "fmt".
> */
> if (present != tv_false)
> {
> expand_fmt_recursive(jsonval->val.binary.data, buf);
> expanded = true;
> }
> }
> return expanded;
> }
This looks better, I have included this change.
The attached v68 version patch has the changes for the same.
Regards,
Vignesh
Attachment | Content-Type | Size |
---|---|---|
v68-0005-DDL-messaging-infrastructure-for-DDL-replication.patch | text/x-patch | 41.9 KB |
v68-0001-Infrastructure-to-support-DDL-deparsing.patch | text/x-patch | 37.3 KB |
v68-0002-Functions-to-deparse-Table-DDL-commands.patch | text/x-patch | 131.3 KB |
v68-0004-Introduce-the-test_ddl_deparse_regress-test-modu.patch | text/x-patch | 47.4 KB |
v68-0003-Support-DDL-deparse-of-the-rest-commands.patch | text/x-patch | 201.3 KB |
v68-0006-Support-DDL-replication.patch | text/x-patch | 212.3 KB |
v68-0007-Document-DDL-replication-and-DDL-deparser.patch | text/x-patch | 40.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-02-10 16:24:11 | Re: Support logical replication of DDLs |
Previous Message | Tom Lane | 2023-02-10 15:03:52 | Re: valgrind a background worker |
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2023-02-10 16:24:11 | Re: Support logical replication of DDLs |
Previous Message | Jeff Davis | 2023-02-10 16:14:20 | Re: ICU locale validation / canonicalization |