Re: BUG #19643: Output of jsonb_populate_recordset not consistent with documentation description

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.

In response to

Browse pgsql-bugs by date

  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