Fix JdbcRecordCursor.isNull for types mapped to slice

[elonazoulay]

This fixes an issue when the postgresql plugin is
used to connect to cockroachdb: https://go.crdb.dev/issue-v/40195/v20.1

[electrum]

Is that link right? I don't see how it relates to this issue.

[electrum]

I'm not sure this is the correct fix. There are various types mapped to Slice including long decimal, varbinary, etc., for which calling getString() actually seems less appropriate than getObject(). Which data types require calling getString() rather than getObject()? It might be better to add a specific PostgreSQL fix for just those types.

[findepi]

I do not see a reason why resultSet.getString() should be better than resultSet.getObject().
The code is redundant and can easily be accidentally removed with a refactor.
Can we have a test for this?

Also, if this is cockrach specific behavior, the correct approach is to provide SliceReadFunction and implement isNull for that case.

See comments

[findepi]

@elonazoulay would it be possible to have a real cockroachdb connector?
For example, we have a a Redshift connector even though PostgreSQL connector "somewhat works" for Redshift.
Or, we're adding Yugabyte connector even though Cassandra connector "mostly works" for Yugabyte (#5352).
I think Cockroach DB is a similar story.

[findepi]

It seems it should be pretty straightforward to test too, given https://www.testcontainers.org/modules/databases/cockroachdb/ exists.

[elonazoulay]

@findepi, yes! We were thinking to add time travel as well, so queries via the presto connector minimize contention with operational queries: https://www.cockroachlabs.com/docs/stable/as-of-system-time.html

[mosabua]

👋 @elonazoulay - this PR has become inactive. If you're still interested in working on it, please let us know, and we can try to get reviewers to help with that.

Also I started a cockroachdb connector PR, but it became stale. Anyone interested can take it over or start again. See https://github.com/simpligility/trino/tree/cockroachdb and #13771 and #8317

We're working on closing out old and inactive PRs, so if you're too busy or this has too many merge conflicts to be worth picking back up, we'll be making another pass to close it out in a few weeks.