Fix collation exposed for scalar function in FROM.

One code path in addRangeTableEntryForFunction() neglected to assign
a collation to the tupdesc entry it constructs (which is a bit odd
considering the other path did do so).  This didn't matter before commit
5815696bc, because nothing would look at the type data in this tupdesc;
but now it does.

While at it, make sure we assign the correct typmod as well.  Most
function expressions don't have a determinate typmod, but some do.

Per buildfarm, which showed failures in non-C collations, a case
I'd not thought to test for this patch :-(

diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c
index d7c4bae8ccfee8bbc5241de8b5bd689f7714535c..2e0c278f355d687bfb5dafbb04566b4a4303fcf3 100644 (file)
--- a/src/backend/parser/parse_relation.c
+++ b/src/backend/parser/parse_relation.c
@@ -1781,8 +1781,11 @@ addRangeTableEntryForFunction(ParseState *pstate,
                               chooseScalarFunctionAlias(funcexpr, funcname,
                                                         alias, nfuncs),
                               funcrettype,
-                              -1,
+                              exprTypmod(funcexpr),
                               0);
+           TupleDescInitEntryCollation(tupdesc,
+                                       (AttrNumber) 1,
+                                       exprCollation(funcexpr));
        }
        else if (functypclass == TYPEFUNC_RECORD)
        {
@@ -1882,12 +1885,15 @@ addRangeTableEntryForFunction(ParseState *pstate,
 
        /* Add the ordinality column if needed */
        if (rangefunc->ordinality)
+       {
            TupleDescInitEntry(tupdesc,
                               (AttrNumber) ++natts,
                               "ordinality",
                               INT8OID,
                               -1,
                               0);
+           /* no need to set collation */
+       }
 
        Assert(natts == totalatts);
    }