Only cast LONG32 to text on PG to avoid type comparison related issues

[beikov]

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

[hibernate-github-bot]

Thanks for your pull request!

This pull request does not follow the contribution rules. Could you have a look?

❌ All commit messages should start with a JIRA issue key matching pattern HHH-\d+
    ↳ Offending commits: [9bed471, c7f7602]

› This message was automatically generated.

[gavinking]

@beikov Why are you proposing to do this?

[gavinking]

Remember that we have defined LONG32VARCHAR to mean:

In principle, the type must accommodate strings of length 2147483647, though this is not an absolutely hard requirement, since such large strings do not occur in practice.

But PostgreSQL looks like it has the following upper limit for varchar:

hreact=# create table V(V varchar(2147483647));
ERROR:  length for type varchar cannot exceed 10485760
LINE 1: create table V(V varchar(2147483647));
                         ^

which is about two orders of magnitude too small.

[beikov]

See the discussion on Zulip for details: https://hibernate.zulipchat.com/#narrow/channel/132094-hibernate-orm-dev/topic/PostgreSQL.20text.20vs.2E.20varchar.20weirdness

[beikov]

For context, blindly casting to text, which is what we are doing right now, leads to issues like this one: https://ci.hibernate.org/view/ORM/job/hibernate-orm-nightly/job/main/687/testReport/junit/org.hibernate.orm.test.function.array/ArrayContainsTest/Build___postgresql_12___Test___testNodeBuilderArray_SessionFactoryScope_/

Performance problems like https://hibernate.atlassian.net/browse/HHH-18780 are also possible.