On 9/27/23 12:44, Dave Cramer wrote:
Good Day Vladimir
On 9/27/23 09:03, Vladimir Sitnikov wrote:
>> so there was the option to change this to false and recompile
> We try doing our best to keep backward compatibility both
> compilation-wise and behaviour-wise.
> However, we treat "private fields and methods" as private, and we do
> not expect people would depend on them.
> If you have to modify sources or depend on private APIs I would
> suggest raising an issue or PR so it could be incorporated
> into the driver itself.
>
> Would you please provide a test case of what you are doing with PgArray?
> What is exactly the sequence of JDBC calls, the actual and the
> expected outcomes in your case?
E.g. for the case of floats, we have to change all:
java.sql.Array arr = rs.getArray(1);
Object objarr = arr.getArray();
float flarr[] = (float[]) objarr;
to
java.sql.Array arr = rs.getArray(1);
Object objarr = arr.getArray();
Float flarr[] = (Float[]) objarr;
So the problem with using float instead of Float is that it is impossible to have a null float and arrays can have nulls.
Thanks Dave, we wrote much of the code before 2008, and we had to implement our own version of nulls in arrays of primitives. So this code was stuck everywhere. Plus we got like 120+ remote sites (slaves) ( which run ... even older code) so we must fully support them as well. Its only about 200 source files in the central system's repo, so we will have to do it sooner or later.
The hard part would be migrating from pgsql 10 to 16.