On 9/25/21 06:59, Tom Lane wrote:
> Etsuro Fujita <etsuro.fujita@gmail.com> writes:
>> On Sat, Sep 25, 2021 at 4:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Longer-term, it seems like we really have to be able to represent
>>> the notion of a remote column that has an "unknown" collation (that
>>> is, one that doesn't match any local collation, or at least is not
>>> known to do so).
>
>> +1
>
>> In addition, a) we should detect whether local “default” matches
>> remote “default”,
>
> If we had a way to do that, most of the problem here wouldn't exist.
> I don't believe we can do it reliably. (Maybe we could put it on
> the user to tell us, say via a foreign-server property?)
A related situation is local and remote servers having different
versions of glibc - in particular, pre versus post 2.28. I think there's
still a major brewing storm here that hasn't yet fully hit the world of
PG users.
I know PG throws the warning message for queries using the wrong
collation library version, but I can't remember - does the query still
execute? If so, then glibc 2.28 seems to significnatly raise the
likelihood of wrong query results across the entire global PG install base.
Does PostgreSQL handle cases which involve FDWs (ala this thread) or hot
standbys? Would be nice if some approach could be found to solve that
problem at the same time as the one discussed on this thread.
-Jeremy
--
Jeremy Schneider
Database Engineer
Amazon Web Services