Re: FmgrInfo allocation patterns (and PL handling as staged programming) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FmgrInfo allocation patterns (and PL handling as staged programming)
Date
Msg-id 3531057.1744047289@sss.pgh.pa.us
Whole thread Raw
In response to Re: FmgrInfo allocation patterns (and PL handling as staged programming)  (Chapman Flack <jcflack@acm.org>)
List 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



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: [PoC] Federated Authn/z with OAUTHBEARER
Next
From: Tom Lane
Date:
Subject: Re: Modern SHA2- based password hashes for pgcrypto