From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | PostgreSQL <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Varying results when using merge joins over postgres_fdw vs hash joins |
Date: | 2017-09-20 15:30:16 |
Message-ID: | CADkLM=cZC5hdANm5OTgUvDAX3y7GASTt61qxsYxKA7FGAXx4Fw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> The collation column is empty here, which means that collation for
> str* columns is default collation i.e. C. This isn't true, since the
> default ncollation on the foreign server is different from the default
> collation of local database. AFAIU, import foreign schema should have
> set appropriate collation of the foreign table.
>
That's what we saw. The query inside IMPORT FOREIGN SCHEMA assumes a NULL
collation means default, without asking the server what that default is. I
was thinking that we could change the select
inside postgresImportForeignSchema and replace
collname,
with something borrowed from information_schema.sql like
coalesce(collname, (SELECT encoding FROM pg_catalog.pg_database
WHERE datname = pg_catalog.current_database()))
which itself isn't right because encoding names don't match up perfectly
with collation names.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-09-20 15:40:02 | Re: Varying results when using merge joins over postgres_fdw vs hash joins |
Previous Message | Tom Lane | 2017-09-20 15:29:21 | Re: src/test/subscription/t/005_encoding.pl is broken |