Horton

Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails

Etsuro Fujita <etsuro.fujita@gmail.com>

View thread View on postgr.es
From: Etsuro Fujita <etsuro.fujita@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Neil Chen <carpenter.nail.cz@gmail.com>
Date: 2021-09-26T08:56:57Z
Lists: pgsql-bugs, pgsql-hackers 
On Sat, Sep 25, 2021 at 10:59 PM Tom Lane <tgl@sss.pgh.pa.us> 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?)

Yeah, I was thinking we could get it from a server option.  Also, I
was thinking this bit might be back-patchable independently of the
solution mentioned above.

Best regards,
Etsuro Fujita

Commits

  1. Doc: extend warnings about collation-mismatch hazards in postgres_fdw.

  2. Add support for asynchronous execution.

  3. Suppress unnecessary RelabelType nodes in yet more cases.