Re: BUG #16583: merge join on tables with different DB collation behind postgres_fdw fails
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org, jurafejfar@gmail.com
Date: 2021-01-28T16:44:09Z
Lists: pgsql-bugs, pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: > I have studied this patch and this functionality. I don't think > collation differences between remote and local instances are handled > sufficiently. This bug report and patch addresses one particular case, > where the database-wide collation of the remote and local instance are > different. But it doesn't handle cases like the same collation name > doing different things, having different versions, or different > attributes. Yeah, agreed. I don't think it's practical to have a 100% solution. I'd make a couple of points: * The design philosophy of postgres_fdw, to the extent it has one, is that it's the user's responsibility to make sure that the local declaration of a foreign table is a faithful model of the actual remote object. There are certain variances you can get away with, but in general, if it breaks it's your fault. (Admittedly, if the local declaration was created via IMPORT FOREIGN SCHEMA, we would like to be sure that it's right without help. But there's only so much we can do there. There are already plenty of ways to fool IMPORT FOREIGN SCHEMA anyway, for example if the same type name refers to something different on the two systems.) * Not being able to ship any qual conditions involving collatable datatypes seems like an absolutely unacceptable outcome. Thus, I don't buy your alternative of not letting the planner make any assumptions at all about compatibility of remote collations. I think that what this patch is basically doing is increasing the visibility of collation compatibility as something that postgres_fdw users need to take into account. Sure, it's not a 100% solution, but it improves the situation, and it seems like we'd have to do this anyway along the road to any better solution. If you've got ideas about how to improve things further, by all means let's discuss that ... but let's not make the perfect be the enemy of the good. regards, tom lane
Commits
-
Doc: extend warnings about collation-mismatch hazards in postgres_fdw.
- 2aa255588756 9.6.24 landed
- 1d7e8e772453 10.19 landed
- b274c982db67 11.14 landed
- 97c5651cea0f 12.9 landed
- 7b0be9fb2ddd 15.0 landed
- 739b872f6c98 13.5 landed
- 02c4e3533926 14.0 landed
-
Add support for asynchronous execution.
- 27e1f14563cf 14.0 cited
-
Suppress unnecessary RelabelType nodes in yet more cases.
- 814a57065ec9 12.5 landed
- 69ffc2f83899 13.0 landed
- 207293240780 14.0 landed