| 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 |
| 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 |