From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL mailing lists <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14849: jsonb_build_object doesn't like VARIADIC calls very much |
Date: | 2017-10-19 02:07:03 |
Message-ID: | CAB7nPqSr+3jHmoQvTX=MNeWMC0OTKf+tdn6uL9rgs1x4qgs22g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Thu, Oct 19, 2017 at 2:54 AM, Andrew Dunstan
<andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
> On 10/18/2017 11:47 AM, Dmitry Dolgov wrote:
>> > On 16 October 2017 at 02:08, Michael Paquier
>> Hm...did you mean `jsonfuncs.c` and `jsonapi.h`? It seems to me, that this
>> potential function (to handle `variadic` case) would not really
>> pollute it.
I think it is not a good idea to make jsonapi.h depend on anything
higher-level than what is now in that. And adding this routine would
require including fmgr.h. We cannot move everything to jsonfuncs.c as
well per the dependencies to json_add and jsonb_add for each build
routine. Or we could move everything but that would be really
disturbing for back-patching.
> If we really wanted to we could have it as a parameter to the function
> to do the special UNKNOWNOID handling or not.
If you are fine with more stuff included in jsonapi.h, that's doable
then, but I don't recommend it. As you are the original author of this
code after all, I will rely on your opinion, so shaping it the way you
see suited better will be fine for me. We could also create a new
header like jsoncommon.h which includes more high-level code. Still
that would be unsuited for back-branches.
> But I'm not sure it's worth it, especially on the back branches where we
> should try to do minimal code disturbance.
Agreed. So for both HEAD and back-branches, my current recommendation
is just to have two functions, one in json.c and jsonb.c, which are in
charge of extracting the argument values, types and NULL-ness flags to
minimize the code duplication. And this also does not cause any huge
disturbing refactoring.
if (nargs % 2 != 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("invalid number of arguments: object must be
matched key value pairs")));
+ errmsg("argument list must have even number of elements"),
+ errhint("The arguments of jsonb_build_object() must
consist of alternating keys and values.")));
I have noticed as well that the error message for jsonb_build_object
is for an uneven number of arguments is inconsistent with its json-ish
cousin. So I reworded things in a more consistent way.
Please see the attached patch which considers all the discussion done,
which shapes the code in the way I see most suited for HEAD and
back-branches.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
json_variadic_v3.patch | application/octet-stream | 20.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2017-10-19 04:19:37 | Re: Improper const-evaluation of HAVING with grouping sets and subquery pullup |
Previous Message | David G. Johnston | 2017-10-18 21:09:41 | Re: ON COMMIT DROP unstable behaviour |
From | Date | Subject | |
---|---|---|---|
Next Message | Ronald Jewell | 2017-10-19 02:53:16 | I've just started working on Full Text Search with version 10 on Ubuntu 16 |
Previous Message | Andres Freund | 2017-10-19 00:03:34 | Re: Fix performance degradation of contended LWLock on NUMA |