On Wed, Sep 20, 2017 at 9:06 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > It is that. I'm tempted to propose that we invent some kind of "unknown" > collation, which the planner would have to be taught to not equate to any > other column collation (not even other instances of "unknown"), and that > postgres_fdw's IMPORT ought to label remote columns with that collation > unless specifically told to do otherwise. Then it's on the user's head > if he tells us to do the wrong thing; but we won't produce incorrect > plans by default. > > This is, of course, not at all a back-patchable fix.
I would like postgres_fdw to be taught about collation versioning, so that postgres_fdw's IMPORT could automatically do the right thing when ICU is in use. Maybe it's too early to discuss that, because we don't even support alternative collation provider collations as the database/cluster default collation just yet. FWIW, postgres_fdw + collations was one of the issues that made me believe in the long term strategic importance of ICU. Anyway, I'm pretty sure that we also need to do something about this in the short term. Maybe a prominent warning about server collation in the postgres_fdw docs, or a user-visible NOTICE when incompatible server collations are observed by postgres_fdw's IMPORT? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers