adds equals implementation for PgArray

[vishalvrv9]

All Submissions:

• Have you followed the guidelines in our Contributing document?

New Feature Submissions:

1. Does your submission pass tests?
2. Does ./gradlew styleCheck pass ?
3. Have you added your new test classes to an existing test suite in alphabetical order?

This PR aims to add implementation of equals() for PgArray #3170

For the hashcode() implementation, I've used https://www.baeldung.com/java-objects-hash-vs-objects-hashcode as reference

I have also added a few tests.

@davecramer @vlsi @sehrope suggestions are welcome.

[davecramer]

@bokken Thoughts on this ?

[bokken]

I still have the questions from the issue: #3170 (comment)

[vishalvrv9]

Answering the questions asked in #3170 below based on my understanding and usage of pgjdbc and as mentioned in #3170

Should it mean they represent the same logical contents?
Should it mean the contain the exact same literal data?

I think both of the above constraints should be true i.e. it should have the same logical contents (fieldString/fieldBytes) as well as the same literal data to consider 2 PgArray instances equal.

If a select statement which returns an array is executed 10 times in a row, should all of the PgArray instances be considered equal?

If the oids are same (which would be if they are the same type of array), have the same logical content (i.e. the row hasn't been updated amidst execution of returning array 10 times) and the same literals, it would be safe to consider them equal? Am I missing something?

or rather, would there be a case when equality should exist even though the logical contents and literal data might differ?

[bokken]

The problem is that the same logical context can be represented in multiple ways. The most obvious example is string vs binary representation.

My question about executing 10 selects in a row speaks directly to this difference. By default, the first 5 will return the string representation and all subsequent will return the binary.

This pr would not consider those 2 different representations of the same logical content as equal.

[vishalvrv9]

Okay. Fair. I wasn't aware of the nature of first 5 selects returning the string representation and subsequent ones returning the binary. (where can I look to understand this behaviour better?)

In order to solve this, I'm thinking the below approach could be adopted:
Always checking the equality for only one of the type - either, byte arrays or fieldStrings i.e. even if we get field strings/bytes we first convert/encode them into bytes/strings and then check for equality.

But it makes me wonder, if the first 5 selects are string and the subsequent ones are binary, is it guaranteed that the binary representation would be valid and converting them to string would yield something can would have been stored as a fieldString if it was executed earlier?

[bokken]

There are multiple string representations which are logically equal. This is a significant part of why I do not believe that implementing equals and hashCode for PgArray is appropriate.

…

On Mon, Apr 15, 2024 at 2:25 PM Vishal Raj ***@***.***> wrote: Okay. Fair. I wasn't aware of the nature of first 5 selects returning the string representation and subsequent ones returning the binary. (where can I look to understand this behaviour better?) In order to solve this, I'm thinking the below approach could be adopted: Always checking the equality for only one of the type - either, byte arrays or fieldStrings i.e. even if we get field strings/bytes we first convert/encode them into bytes/strings and then check for equality. But it makes me wonder, if the first 5 selects are string and the subsequent ones are binary, is it guaranteed that the binary representation would be valid and converting them to string would yield something can would have been stored as a fieldString if it was executed earlier? — Reply to this email directly, view it on GitHub <#3174 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW3U3MMEUEZ3BZ5U2LNKKTY5QSSVAVCNFSM6AAAAABFCBFKM6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJXGY2DMMJUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>