On Wed, Sep 20, 2017 at 9:06 AM, Tom Lane <tgl@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