From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <jcflack(at)acm(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FmgrInfo allocation patterns (and PL handling as staged programming) |
Date: | 2025-04-07 17:34:49 |
Message-ID: | 3531057.1744047289@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chapman Flack <jcflack(at)acm(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-07 17:50:35 | Re: Modern SHA2- based password hashes for pgcrypto |
Previous Message | Jacob Champion | 2025-04-07 17:32:31 | Re: [PoC] Federated Authn/z with OAUTHBEARER |