| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Fix collation exposed for scalar function in FROM. |
| Date: | 2020-01-02 18:49:00 |
| Message-ID: | E1in5Wm-0004QZ-R1@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
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 :-(
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/4d02eb017e3c1268762fd1a10ec3c569515c047d
Modified Files
--------------
src/backend/parser/parse_relation.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-01-02 18:50:37 | Re: pgsql: Make parser rely more heavily on the ParseNamespaceItem data str |
| Previous Message | Alvaro Herrera | 2020-01-02 18:40:59 | Re: pgsql: Update copyrights for 2020 |