From: Chapman Flack <jcflack@acm.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date: Sun, 6 Apr 2025 19:27:22 -0400
Message-ID: <67F30DDA.4000509@acm.org> (raw)
In-Reply-To: <2978258.1743968866@sss.pgh.pa.us>
References: <67F2B767.9040507@acm.org>
<2965818.1743960827@sss.pgh.pa.us>
<67F2D87F.1000709@acm.org>
<2978258.1743968866@sss.pgh.pa.us>
On 04/06/25 15:47, Tom Lane wrote:
> Chapman Flack <jcflack@acm.org> writes:
>> Can a spread-out variadic "any" arg list ever vary
>> in length or type on the fly at a single call site?
>
> Don't think so.
Only slightly tangentially: what things count as "objects that depend
on the transform" for purposes of DROP TRANSFORM ... CASCADE / RESTRICT ?
I just now dropped (in 17.4) a transform named in an existing routine's
declaration, with nary a peep.
I'm not, for now, complaining, as my objective was to make sure my
dispatcher noticed that, when dispatching to the routine, and if DROP
TRANSFORM had refused, I'd have had to work harder.
Right now the dispatcher is only checking before validate or prepare though.
If transforms can really just vanish I'd better check even when dispatching
to a cached version.
I suppose a cached routine could continue merrily along using
the vanished transform's functions, as long as they haven't vanished.
But once the transform is dropped there's nothing saying you can't
drop the functions, and that could get weird.
Or, is somehow registering a routine's dependency on a transform
something that its PL handler is responsible for doing? I could sort
of see that, given that it's the PL that has to make whatever actual
transformation happens, happen. But relying on the PL to record the
dependency would seem brittle, what with validators not running
for sure in all circumstances.
Regards,
-Chap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jcflack@acm.org, tgl@sss.pgh.pa.us
Subject: Re: FmgrInfo allocation patterns (and PL handling as staged programming)
In-Reply-To: <67F30DDA.4000509@acm.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox