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@tao11.riddles.org.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 =3D inet, subtype_diff =3D
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=3D# create index inetr_idx on inetr using gist (r);
ERROR:  result is out of range
CONTEXT:  SQL function "inet_subdiff" statement 1

postgres=3D# 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.