diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-01-02 13:48:54 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-01-02 13:48:54 -0500 |
commit | 4d02eb017e3c1268762fd1a10ec3c569515c047d (patch) | |
tree | 33b3e3824a6c5cdeb48b11b604e1bfbda879aa1d | |
parent | 5815696bc66b3092f6361f53e0394909647042c8 (diff) | |
download | postgresql-4d02eb017e3c1268762fd1a10ec3c569515c047d.tar.gz postgresql-4d02eb017e3c1268762fd1a10ec3c569515c047d.zip |
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 :-(
-rw-r--r-- | src/backend/parser/parse_relation.c | 8 |
1 files changed, 7 insertions, 1 deletions
diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index d7c4bae8ccf..2e0c278f355 100644 --- 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); } |