Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 4d02eb0

Browse files
committed
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 5815696, 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 :-(
1 parent 5815696 commit 4d02eb0

File tree

1 file changed

+7
-1
lines changed

1 file changed

+7
-1
lines changed

src/backend/parser/parse_relation.c

+7-1
Original file line numberDiff line numberDiff line change
@@ -1781,8 +1781,11 @@ addRangeTableEntryForFunction(ParseState *pstate,
17811781
chooseScalarFunctionAlias(funcexpr, funcname,
17821782
alias, nfuncs),
17831783
funcrettype,
1784-
-1,
1784+
exprTypmod(funcexpr),
17851785
0);
1786+
TupleDescInitEntryCollation(tupdesc,
1787+
(AttrNumber) 1,
1788+
exprCollation(funcexpr));
17861789
}
17871790
else if (functypclass == TYPEFUNC_RECORD)
17881791
{
@@ -1882,12 +1885,15 @@ addRangeTableEntryForFunction(ParseState *pstate,
18821885

18831886
/* Add the ordinality column if needed */
18841887
if (rangefunc->ordinality)
1888+
{
18851889
TupleDescInitEntry(tupdesc,
18861890
(AttrNumber) ++natts,
18871891
"ordinality",
18881892
INT8OID,
18891893
-1,
18901894
0);
1895+
/* no need to set collation */
1896+
}
18911897

18921898
Assert(natts == totalatts);
18931899
}

0 commit comments

Comments
 (0)