The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation: not tested
Hi, Thanks for the patch. I am afraid I will have to :-1: this patch. Of course it is possible that I am wrong, so please correct me if you, or any other reviewers, think so. The problem that is intended to be solved, upon closer inspection seems to be a conscious design decision rather than a problem. Even if I am wrong there, I am not certain that the proposed patch covers all the bases with respect to collations, build-in types, shipability etc for simple expressions, and covers any of more complicated expressions all together. As for the scenario which prompted the patch, you wrote, quote: The real scenario that prompted it is a tickets table with status, priority, category, etc. enums. We don't have plans to modify them any time soon, but if we do it's got to be coordinated and deployed across two databases, all so we can use what might as well be a text column in a single WHERE clause. Since foreign tables can be defined over subsets of columns, reordered, and names changed, a little opt-in flexibility with types too doesn't seem misplaced. end quote. I will add that creating a view on the remote server with type flexibility that you wish and then create foreign tables against the view, might address your problem. Respectfully, //Georgios
