| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | yishundinesh(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19643: Output of jsonb_populate_recordset not consistent with documentation description |
| Date: | 2026-08-28 13:28:02 |
| Message-ID: | CAKFQuwbnciGxztrBCEDSe2-Oj9UEiH3yFhEAmf4B8D7TO8KHug@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Aug 28, 2026 at 8:57 AM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:
> The following bug has been logged on the website:
>
> Bug reference: 19643
> Logged by: Balaji Venkatesan
> Email address: yishundinesh(at)gmail(dot)com
> PostgreSQL version: 18.6
> Operating system: Ubuntu
> Description:
>
> As per the documentation jsonb_populate_record "Expands the object in
> from_json to a row whose columns match the record type defined by base".
> The example given the documentation is working fine, but if I replace
> null::myrow with Row(('a'::text,'b'::text), the output discards
> from_json(second argument completely)
> First argument's value is being used instead of using it as a key
>
> Eg:
> select * from
>
> jsonb_populate_recordset(ROW('a'::text,'b'::text),'[{"a":"test","b":"55"}]')
> as (a text, b text)
>
> Output::
> a,b
>
> Expected output:
>
> test,55
>
It doesn't discard the second argument - but your record type doesn't have
either "a" or "b" columns defined so no matches are found.
Your base object has only one unnamed composite typed (two text fields)
column. Since the object itself is not null you've specified a default
value for that column which is what you see in the output.
In short, this is working as documented. What you intended with writing
row(...) simply isn't how the system works.
Use json_to_record or json_to_recordset if you want to specify the
structure of the output explicitly inline. The populate variants are meant
to be used when actual types exist within the system (usually because a
corresponding table exists).
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Rachitskiy | 2026-08-28 19:38:44 | Re: BUG #19641: Unexpected results on an SP-GiST indexed column with a non-deterministic collation |
| Previous Message | David G. Johnston | 2026-08-28 13:16:14 | Re: BUG #19642: Include column name in error message when varchar(n) length limit is exceeded |