aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-01-02 13:48:54 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2020-01-02 13:48:54 -0500
commit4d02eb017e3c1268762fd1a10ec3c569515c047d (patch)
tree33b3e3824a6c5cdeb48b11b604e1bfbda879aa1d
parent5815696bc66b3092f6361f53e0394909647042c8 (diff)
downloadpostgresql-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.c8
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);
}