BUG #7881: SQL function failures in long-lived calling contexts

The following bug has been logged on the website:

Bug reference: 7881
Logged by: Andrew Gierth
Email address: andrew(at)tao11(dot)riddles(dot)org(dot)uk
PostgreSQL version: 9.2.3
Operating system: any
Description:

The range type code accepts SQL functions for subtype_diff, but stores the
flinfo in a long-lived context (typcache).

The SQL function handler, fmgr_sql, isn't prepared to deal with the
possibility that the fcache entry may be left over from a previous query
that failed.

The combination of these two allows a non-superuser to provoke at least an
assertion failure as follows:

create or replace function inet_subdiff(inet,inet) returns float8 language
sql immutable as $f$ select ($2 - $1)::float8; $f$;

create type inetrange as range (subtype = inet, subtype_diff =
inet_subdiff);

create table inetr as select
format('[%s::,%s::]',to_hex(i),to_hex(i+1))::inetrange as r from
generate_series(0,65534) i;

postgres=# create index inetr_idx on inetr using gist (r);
ERROR: result is out of range
CONTEXT: SQL function "inet_subdiff" statement 1

postgres=# create index inetr_idx on inetr using gist (r);
TRAP: FailedAssertion("!(snapshot->regd_count > 0)", File: "snapmgr.c",
Line: 557)

I'm inclined to think this is fmgr_sql's fault for apparently assuming that
if an error is thrown that it'll never see the fcache entry again, but in
this example that's clearly not true.