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: Mon, 7 Apr 2025 13:26:37 -0400
Message-ID: <67F40ACD.7040507@acm.org> (raw)
In-Reply-To: <2968353.1743962392@sss.pgh.pa.us>
References: <67F2B767.9040507@acm.org>
<2965818.1743960827@sss.pgh.pa.us>
<2968353.1743962392@sss.pgh.pa.us>
On 04/06/25 13:59, Tom Lane wrote:
> polymorphic arguments: the element type of an anyarray argument can
> change on-the-fly from one call to the next in the same query. I
> think this is only possible when you're fed pg_stats.most_common_vals
> or one of its sibling columns, but that's enough to be a problem.
> That's why all of our array-munging functions that use fn_extra to
> cache type-dependent state are careful to check the element type
> against the cache every single time.
This was really bumming me out. I thought "what on earth does that do
to the rest of your surrounding query, say if you have anyelement types
in the args or return value also?".
So the answer to that part is easy: if a routine's types include both
anyarray and anyelement (like, say, unnest), it just can't be applied
to one of those statistics columns. An attempt to use it that way in
a query is rejected early, before any attempt to call the routine:
ERROR: cannot determine element type of "anyarray" argument
STATEMENT: select unnest(stavalues1) from pg_statistic limit 1;
Now, if you have a routine that uses anyarray but no corresponding
element pseudotype, you are allowed to apply that to a statistics
column. It can even have anyarray as a return/output type also.
When it's applied to a statistics column, here's what my dispatcher sees:
# select foo(stavalues1) from pg_statistic limit 1;
RegProcedure[1255,16861,0]public.foo essentialChecks: checkBody true
RegProcedure[1255,16861,0]public.foo prepare():
inputsTemplate : [RegType.Unresolved[1247,2277,0]pg_catalog.anyarray]
unresolvedInputs : {0}
outputsTemplate : [RegType.Unresolved[1247,2277,0]pg_catalog.anyarray]
unresolvedOutputs: {0}
RegProcedure[1255,16861,0]public.foo Template.specialize():
precomputed id : 39d9314d
inputsDescriptor : [RegType.Unresolved[1247,2277,0]pg_catalog.anyarray]
inputsAreSpread : false
stableInputs : {}
outputsDescriptor: [RegType.Unresolved[1247,2277,0]pg_catalog.anyarray]
So the polymorphic type resolution applied at specialize() time
"succeeded", raised no error, and left the pseudotype anyarray
in both the inputs and outputs supposedly-"resolved" results.
That seems to make for a tidy way of recognizing the situation. If
you go to specialize and find anyarray among your supposedly-resolved
call-site types, well, you know you're in Wonderland and can adjust
behavior accordingly.
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: <67F40ACD.7040507@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