Improve the handling of result type coercions in SQL functions.
authorTom Lane <tgl@sss.pgh.pa.us>
Wed, 8 Jan 2020 16:07:53 +0000 (11:07 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Wed, 8 Jan 2020 16:07:59 +0000 (11:07 -0500)
commit913bbd88dc6b859c70ebb48107b38d693c4c6673
tree5a6f17fd59677039ad33cd91e69ce1b7e03b8c43
parent8dd1511e39acd729020e151deb15a958300ebff5
Improve the handling of result type coercions in SQL functions.

Use the parser's standard type coercion machinery to convert the
output column(s) of a SQL function's final SELECT or RETURNING
to the type(s) they should have according to the function's declared
result type.  We'll allow any case where an assignment-level
coercion is available.  Previously, we failed unless the required
coercion was a binary-compatible one (and the documentation ignored
this, falsely claiming that the types must match exactly).

Notably, the coercion now accounts for typmods, so that cases where
a SQL function is declared to return a composite type whose columns
are typmod-constrained now behave as one would expect.  Arguably
this aspect is a bug fix, but the overall behavioral change here
seems too large to consider back-patching.

A nice side-effect is that functions can now be inlined in a
few cases where we previously failed to do so because of type
mismatches.

Discussion: https://postgr.es/m/18929.1574895430@sss.pgh.pa.us
doc/src/sgml/xfunc.sgml
src/backend/catalog/pg_proc.c
src/backend/executor/functions.c
src/backend/optimizer/util/clauses.c
src/include/executor/functions.h
src/test/regress/expected/rangefuncs.out
src/test/regress/sql/rangefuncs.sql