Ireneusz Pluta <ipluta@wp.pl> writes:
> W dniu 2018-07-20 o 18:39, Andres Freund pisze:
>> You're probably going to have a higher likelihood of getting the bug
>> fixed quickly if you'd include a full reproducer.
> Sure, but RhodiumToad was so kind promising to follow up on this, so I skipped that chore :-).
It may be a bug, but I'm afraid it's a can't-fix one, at least for the
foreseeable future. postgres_fdw is correctly determining that the
date_trunc function's input collation is being chosen on the basis of a
defaultly-collated literal, and that makes it unsafe to ship. The
situation is not different from the case of, say,
'foo'::text > 'bar'::text
(ignoring the likelihood that that'd get const-folded before it got here).
If that expression is evaluated locally, the result will depend on the
local database's default collation; whereas if we send it for remote
execution, the result will depend on the remote database's default
collation, and could very well be different.
In reality, date_trunc() pays no attention to its input collation; but
postgres_fdw has no way to know that, so it can't safely ship this
expression.
If we had a way to know that the remote database's default collation acts
the same as the local one's, we could use different and more forgiving
rules about what can be shipped; but I'm not sure how we could know that
reliably. (We could perhaps check that it was named the same, but in
cross-platform situations that proves little.)
Alternatively, if postgres_fdw could know which functions don't really
pay attention to their input collation, it could skip this check for
those functions. But that's not an easy thing to fix either.
regards, tom lane