On 13.08.2020 20:00, Tom Lane wrote:
Konstantin Knizhnik <k.knizh...@postgrespro.ru> writes:
Right now jsonb functions are treated as non-shippable by postgres_fdw
and so predicates with them are not pushed down to foreign server:
Yeah, that's kind of annoying, but breaking the collation check
is not an acceptable fix.  And what you're proposing *does* break it.
The issue here is that the function's input collation is coming from
the default collation applied to the text constant, and we can't assume
that that will be the same on the remote side.

In reality, of course, jsonb_exists doesn't care about its input collation
--- but postgres_fdw has no way to know that.  I don't see any easy way
around that.

One idea that would probably work in a lot of postgres_fdw usage scenarios
is to have a foreign-server-level flag that says "all the collations on
that server behave the same as the local ones, and the default collation
is the same too", and then we just skip the collation checking altogether.
But I'm a bit worried that if someone mistakenly sets that flag, the
misbehavior will be very hard to detect.

                        regards, tom lane
Thank you for clarification.
And sorry for mistyping in topic (there should be "collation" instead of "collection"). Actually I do not know much about handling collations in Postgres and particularly in postgres_fdw. Can you (or somebody else) provide more information about this fragment of code:
                /*
                 * If function's input collation is not derived from a foreign
                 * Var, it can't be sent to remote.
                 */
                if (fe->inputcollid == InvalidOid)
                     /* OK, inputs are all noncollatable */ ;
                else if (inner_cxt.state != FDW_COLLATE_SAFE ||
                         fe->inputcollid != inner_cxt.collation)
                    return false;

So we have function call expression which arguments have associated collation,
but function itself is collection-neutral: funccollid = 0
Why it is not safe to push this function call to the remote server?
Why it breaks collation check?
If there are some unsafe operations with collations during argument evaluation, then
we detect it while recursive processing of arguments.

I agree that my proposed fix is not correct.
But what about this check:

                if (fe->inputcollid == InvalidOid)
                     /* OK, inputs are all noncollatable */ ;
                else if (fe->funccollid == InvalidOid)
                     /* OK, function is noncollatable */ ;

Or funccollid=0 doesn't mean that collations of function arguments do not affect function behavior?



Reply via email to