Re: POC: PLpgSQL FOREACH IN JSON ARRAY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: POC: PLpgSQL FOREACH IN JSON ARRAY
Date: 2026-07-23 18:07:07
Message-ID: 1474498.1784830027@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> st 1. 7. 2026 v 23:40 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:
>> * it's not clear to me that these routines have any business knowing
>> about the "target type"; they certainly shouldn't contain comments
>> alluding to PLpgSQL's conversion abilities. I think probably you
>> just want them to pass back the data type they are producing and
>> let PLpgSQL decide whether it wants to convert or not.

> The iterator should know the target type for more reasons:

I wasn't super convinced by these arguments, so today I tried to
benchmark the performance question by asking Claude Code to do
that. It came up with some interesting results, notably that this
only matters for composite types not scalars. It also suggested
that we could make the API cleaner with minimal performance
loss by inventing a separate "coerce()" callback. As presented,
its patch is a mess because it chose to allow run-time selection
among several different ways, which of course we wouldn't do.
But anyway, take a look at that option and see if it makes sense
to you.

(I should note that the benchmarking was done in a VM on my laptop.
So it's hardly an industrial-strength setup, but since we only
care about single-threaded performance here, I think the results
are probably reasonably trustworthy. Feel free to reproduce for
yourself though.)

regards, tom lane

Attachment Content-Type Size
foreach-benchmark.tar.gz.nocfbot application/gzip 6.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-07-23 18:22:01 Re: Fix race condition in pg_get_publication_tables with concurrent DROP TABLE
Previous Message John Naylor 2026-07-23 16:45:50 Re: [PATCH v4] Make NumericVar storage semantics explicit