Re: pgsql: Rename jsonb_replace to jsonb_set and allow it to add new values
От | Tom Lane |
---|---|
Тема | Re: pgsql: Rename jsonb_replace to jsonb_set and allow it to add new values |
Дата | |
Msg-id | 14172.1433125523@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Rename jsonb_replace to jsonb_set and allow it to add new values (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: pgsql: Rename jsonb_replace to jsonb_set and allow
it to add new values
|
Список | pgsql-committers |
Andrew Dunstan <andrew@dunslane.net> writes: > well, that's what we have a buildfarm for. It looks like this problem is in setPathObject: setPathObject(JsonbIterator **it, Datum *path_elems, bool *path_nulls, int path_len, JsonbParseState **st, int level, Jsonb *newval, uint32 npairs, bool create) { JsonbValue v; int i; JsonbValue k; bool done = false; if (level >= path_len || path_nulls[level]) done = true; /* empty object is a special case for create */ if ((npairs == 0) && create && (level == path_len - 1)) { JsonbValue new = k; new.val.string.len = VARSIZE_ANY_EXHDR(path_elems[level]); new.val.string.val = VARDATA_ANY(path_elems[level]); (void) pushJsonbValue(st, WJB_KEY, &new); Since "k" is undefined at this point, initializing "new" that way is pure hogwash. I'm surprised gcc doesn't complain about it. (BTW, could I lobby to not use "new" as a variable name? lldb gets confused, probably because "new" is a C++ keyword.) regards, tom lane
В списке pgsql-committers по дате отправления: