mirror of
https://github.com/postgres/postgres.git
synced 2025-05-08 07:21:33 +03:00
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 :-(
This commit is contained in:
parent
5815696bc6
commit
4d02eb017e
@ -1781,8 +1781,11 @@ addRangeTableEntryForFunction(ParseState *pstate,
|
|||||||
chooseScalarFunctionAlias(funcexpr, funcname,
|
chooseScalarFunctionAlias(funcexpr, funcname,
|
||||||
alias, nfuncs),
|
alias, nfuncs),
|
||||||
funcrettype,
|
funcrettype,
|
||||||
-1,
|
exprTypmod(funcexpr),
|
||||||
0);
|
0);
|
||||||
|
TupleDescInitEntryCollation(tupdesc,
|
||||||
|
(AttrNumber) 1,
|
||||||
|
exprCollation(funcexpr));
|
||||||
}
|
}
|
||||||
else if (functypclass == TYPEFUNC_RECORD)
|
else if (functypclass == TYPEFUNC_RECORD)
|
||||||
{
|
{
|
||||||
@ -1882,12 +1885,15 @@ addRangeTableEntryForFunction(ParseState *pstate,
|
|||||||
|
|
||||||
/* Add the ordinality column if needed */
|
/* Add the ordinality column if needed */
|
||||||
if (rangefunc->ordinality)
|
if (rangefunc->ordinality)
|
||||||
|
{
|
||||||
TupleDescInitEntry(tupdesc,
|
TupleDescInitEntry(tupdesc,
|
||||||
(AttrNumber) ++natts,
|
(AttrNumber) ++natts,
|
||||||
"ordinality",
|
"ordinality",
|
||||||
INT8OID,
|
INT8OID,
|
||||||
-1,
|
-1,
|
||||||
0);
|
0);
|
||||||
|
/* no need to set collation */
|
||||||
|
}
|
||||||
|
|
||||||
Assert(natts == totalatts);
|
Assert(natts == totalatts);
|
||||||
}
|
}
|
||||||
|
Loading…
x
Reference in New Issue
Block a user