Fix type-checking of RECORD-returning functions in FROM, redux.

Commit 2ed8f9a01 intended to institute a policy that if a
RangeTblFunction has a coldeflist, then the function return type is
certainly RECORD, and we should use the coldeflist as the source of
truth about what the columns of the record type are.  When the
original function has been folded to a constant, inspection of the
constant might give a different answer.  This situation will lead to
a tuple-type-mismatch error at execution, but up until that point we
need to consistently believe the coldeflist, or we'll have problems
from different bits of code reaching different conclusions.

expandRTE didn't get that memo though, and would try to produce a
tupdesc based on the constant in this situation, leading to an
assertion failure.  (Desultory testing suggests that non-assert
builds often manage to give the expected error, although I also
saw a "cache lookup failed for type 0" error, and it seems at
least possible that a crash could happen.)

Some other callers of get_expr_result_type and get_expr_result_tupdesc
were also being incautious about this.  While none of them seem to
have actual bugs, they're working harder than necessary in this case,
besides which it seems safest to have an explicit policy of not using
those functions on an RTE with a coldeflist.  Adjust the code
accordingly, and add commentary to funcapi.c about this policy.

Also fix an obsolete comment that claimed "get_expr_result_type()
doesn't know how to extract type info from a RECORD constant".
That hasn't been true since commit d57534740.

Per bug #18422 from Alexander Lakhin.
As with the previous commit, back-patch to all supported branches.

Discussion: https://postgr.es/m/18422-89ca86c8eac5246d@postgresql.org

diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c
index 6e8f6a57051dc50cffbdb165beae47adcdc07170..d4b5b2ade10a3c3b53f51942d535d47093d7aaa5 100644 (file)
--- a/src/backend/catalog/dependency.c
+++ b/src/backend/catalog/dependency.c
@@ -2337,7 +2337,11 @@ process_function_rte_ref(RangeTblEntry *rte, AttrNumber attnum,
        {
            TupleDesc   tupdesc;
 
-           tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr, true);
+           /* If it has a coldeflist, it certainly returns RECORD */
+           if (rtfunc->funccolnames != NIL)
+               tupdesc = NULL; /* no need to work hard */
+           else
+               tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr, true);
            if (tupdesc && tupdesc->tdtypeid != RECORDOID)
            {
                /*

diff --git a/src/backend/optimizer/prep/prepjointree.c b/src/backend/optimizer/prep/prepjointree.c
index 4badb6ff587833b8fd5395249ba6872f343f0481..fb768ad52c2a1c44bc83c950720c7457056c3f59 100644 (file)
--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -1854,6 +1854,10 @@ pull_up_constant_function(PlannerInfo *root, Node *jtnode,
    if (rtf->funccolcount != 1)
        return jtnode;          /* definitely composite */
 
+   /* If it has a coldeflist, it certainly returns RECORD */
+   if (rtf->funccolnames != NIL)
+       return jtnode;          /* must be a one-column RECORD type */
+
    functypclass = get_expr_result_type(rtf->funcexpr,
                                        &funcrettype,
                                        &tupdesc);

diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index b50fe58d1c12a73e0f3305fd5df71c47ed0b693b..59487cbd795b0e77cfea7bd53461933b9a8e83c3 100644 (file)
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -4431,12 +4431,11 @@ evaluate_function(Oid funcid, Oid result_type, int32 result_typmod,
     * Can't simplify if it returns RECORD.  The immediate problem is that it
     * will be needing an expected tupdesc which we can't supply here.
     *
-    * In the case where it has OUT parameters, it could get by without an
-    * expected tupdesc, but we still have issues: get_expr_result_type()
-    * doesn't know how to extract type info from a RECORD constant, and in
-    * the case of a NULL function result there doesn't seem to be any clean
-    * way to fix that.  In view of the likelihood of there being still other
-    * gotchas, seems best to leave the function call unreduced.
+    * In the case where it has OUT parameters, we could build an expected
+    * tupdesc from those, but there may be other gotchas lurking.  In
+    * particular, if the function were to return NULL, we would produce a
+    * null constant with no remaining indication of which concrete record
+    * type it is.  For now, seems best to leave the function call unreduced.
     */
    if (funcform->prorettype == RECORDOID)
        return NULL;

diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c
index 7ca793a369f3369cb290ce1e708eba3ced506a8e..2f64eaf0e371a82220f54ba97e5d1e81faf61947 100644 (file)
--- a/src/backend/parser/parse_relation.c
+++ b/src/backend/parser/parse_relation.c
@@ -2738,12 +2738,17 @@ expandRTE(RangeTblEntry *rte, int rtindex, int sublevels_up,
                {
                    RangeTblFunction *rtfunc = (RangeTblFunction *) lfirst(lc);
                    TypeFuncClass functypclass;
-                   Oid         funcrettype;
-                   TupleDesc   tupdesc;
+                   Oid         funcrettype = InvalidOid;
+                   TupleDesc   tupdesc = NULL;
+
+                   /* If it has a coldeflist, it returns RECORD */
+                   if (rtfunc->funccolnames != NIL)
+                       functypclass = TYPEFUNC_RECORD;
+                   else
+                       functypclass = get_expr_result_type(rtfunc->funcexpr,
+                                                           &funcrettype,
+                                                           &tupdesc);
 
-                   functypclass = get_expr_result_type(rtfunc->funcexpr,
-                                                       &funcrettype,
-                                                       &tupdesc);
                    if (functypclass == TYPEFUNC_COMPOSITE ||
                        functypclass == TYPEFUNC_COMPOSITE_DOMAIN)
                    {
@@ -3369,6 +3374,10 @@ get_rte_attribute_is_dropped(RangeTblEntry *rte, AttrNumber attnum)
                    {
                        TupleDesc   tupdesc;
 
+                       /* If it has a coldeflist, it returns RECORD */
+                       if (rtfunc->funccolnames != NIL)
+                           return false;   /* can't have any dropped columns */
+
                        tupdesc = get_expr_result_tupdesc(rtfunc->funcexpr,
                                                          true);
                        if (tupdesc)

diff --git a/src/backend/utils/fmgr/funcapi.c b/src/backend/utils/fmgr/funcapi.c
index 5c03704ef9becaff66d1f3e0e8c77b271f079bd4..05d763fa06e4c161c68817582890931f2af49bf5 100644 (file)
--- a/src/backend/utils/fmgr/funcapi.c
+++ b/src/backend/utils/fmgr/funcapi.c
@@ -287,6 +287,13 @@ get_call_result_type(FunctionCallInfo fcinfo,
 /*
  * get_expr_result_type
  *     As above, but work from a calling expression node tree
+ *
+ * Beware of using this on the funcexpr of a RTE that has a coldeflist.
+ * The correct conclusion in such cases is always that the function returns
+ * RECORD with the columns defined by the coldeflist fields (funccolnames etc).
+ * If it does not, it's the executor's responsibility to catch the discrepancy
+ * at runtime; but code processing the query in advance of that point might
+ * come to inconsistent conclusions if it checks the actual expression.
  */
 TypeFuncClass
 get_expr_result_type(Node *expr,
@@ -537,7 +544,8 @@ internal_get_result_type(Oid funcid,
  * if noError is true, else throws error.
  *
  * This is a simpler version of get_expr_result_type() for use when the caller
- * is only interested in determinate rowtype results.
+ * is only interested in determinate rowtype results.  As with that function,
+ * beware of using this on the funcexpr of a RTE that has a coldeflist.
  */
 TupleDesc
 get_expr_result_tupdesc(Node *expr, bool noError)

diff --git a/src/test/regress/expected/rangefuncs.out b/src/test/regress/expected/rangefuncs.out
index 2bda957f43ee0ed3a08cdb49458d833f10b1f045..397a8b35d6d5c2fb1ff900ef6f407fb60e45484b 100644 (file)
--- a/src/test/regress/expected/rangefuncs.out
+++ b/src/test/regress/expected/rangefuncs.out
@@ -2498,3 +2498,6 @@ with a(b) as (values (row(1,2,3)))
 select * from a, coalesce(b) as c(d int, e int, f float);  -- fail
 ERROR:  function return row and query-specified return row do not match
 DETAIL:  Returned type integer at ordinal position 3, but query expects double precision.
+select * from int8_tbl, coalesce(row(1)) as (a int, b int);  -- fail
+ERROR:  function return row and query-specified return row do not match
+DETAIL:  Returned row contains 1 attribute, but query expects 2.

diff --git a/src/test/regress/sql/rangefuncs.sql b/src/test/regress/sql/rangefuncs.sql
index 06d598c5e9bb7f5999ccbf60661544db74e7a8f2..3c47c98e1136d23554b9d9a0791114b53963fc1c 100644 (file)
--- a/src/test/regress/sql/rangefuncs.sql
+++ b/src/test/regress/sql/rangefuncs.sql
@@ -824,3 +824,4 @@ with a(b) as (values (row(1,2,3)))
 select * from a, coalesce(b) as c(d int, e int, f int, g int);  -- fail
 with a(b) as (values (row(1,2,3)))
 select * from a, coalesce(b) as c(d int, e int, f float);  -- fail
+select * from int8_tbl, coalesce(row(1)) as (a int, b int);  -- fail