Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Chapman Flack <jcflack@acm.org>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-07T17:34:49Z
Lists: pgsql-hackers
Chapman Flack <jcflack@acm.org> writes: > 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; Right. AFAIK the oddity doesn't "leak out" of functions taking anyarray. > 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. Cool. regards, tom lane
Commits
-
Fix erroneous construction of functions' dependencies on transforms.
- b73e6d71a89f 18.0 landed
-
Change SQL-language functions to use the plan cache.
- 0dca5d68d7be 18.0 cited