Re: [PATCH] pg_input_is_valid() reuses the first type name inside a PL/pgSQL loop

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Xnerv Wang <xnervwang(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: Re: [PATCH] pg_input_is_valid() reuses the first type name inside a PL/pgSQL loop
Date: 2026-11-13 09:53:56
Message-ID: e5fcf624-a588-4579-883b-e867f548840d@proxel.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/12/26 02:37, Chao Li wrote:
> I'm afraid we don't have a reliable way to determine if the resolved type has changed in pg_input_is_valid_common() without either resolving the type OID. This means the patch only partially addresses the caching problem. Given that, I'd wait and see if the committers have any concerns about this partial fix.
>
> It feels to me that, without some refactoring, the current caching mechanism cannot reliably handle all these cases.

I am not a fan of the caching mechanism and I wonder why the
pg_input_is_valid() should even try to optimize this in the first place.
As an end user of PostgreSQL I would not expect any caching of the
lookup from type name to oid. If this function had been added now I
personally would have preferred the signature to be:

pg_input_is_valid(text, regtype)

Do we have similar optimizations for other functions which take a type name?

--
Andreas Karlsson
Percona

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-11-13 10:07:24 Re: ISBN range table
Previous Message Hayato Kuroda (Fujitsu) 2026-11-13 09:43:17 RE: Injection point: fix race condition between attach and cleanup