SEO

On Mon, 9 Jul 2007, Marek Lewczuk wrote:

>> in the attachment you can find AbstractJdbc2Array class with two fixed
>> features: null value as element of an array and... multi-dimensional
>> arrays support. There are two things related with this two changes:
>> - all arrays are objects arrays (which means that e.g. boolean[] is
>> represented as Boolean[])
>> - when multi-dimensional array is processed then Object[] is returned by
>> getArray() - it's because we can't declare in Java an array of unknown
>> dimension (so if PostgreSQL returns char[][] then jdbc will return
>> Object[], that contains String[] elements)
>>

I gave this a read and have some comments:

1) Your null checking needs to be version dependent. Releases prior to
8.2 do not support null elements and you'll get:

# select array['a','NULL'];
array
----------
{a,NULL}
(1 row)

2) Changing from returning arrays of primitive types to arrays of objects
is necessary for null and multi-dimension support, but will still break
users code all over the place. Not sure what we can do about that other
than put a strong warning in the release notes.

3) A lot of the code doesn't look like it handles multiple dimensions.
What about things like fillIntegerResultSet? No that we're dealing with
objects can't we abstract a lot of these copies away and provide one
implementation that is multi-dimension aware? If you do
Array.getResultSet you should be able to call ResultSet.getArray and the
getResultSet on that, right?

Kris Jurka



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Kris Jurka wrote:

> 2) Changing from returning arrays of primitive types to arrays of
> objects is necessary for null and multi-dimension support, but will
> still break users code all over the place. Not sure what we can do
> about that other than put a strong warning in the release notes.

I was wondering which behaviour was right -- I thought returning
array-of-primitive was correct per the spec at the time I wrote it, and
that's why getArray() returns Object not Object[] -- but now the 1.6
javadoc says:

> Note: When getArray is used to materialize a base type that maps to a primitive data type, then it is implementation-defined whether the array returned is an array of that primitive data type or an array of Object.

So I suppose that .. in theory .. applications should be expecting to
handle both. Ugh.

-O

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Kris Jurka pisze:
> I gave this a read and have some comments:
>
> 1) Your null checking needs to be version dependent. Releases prior to
> 8.2 do not support null elements and you'll get:
>
> # select array['a','NULL'];
> array
> ----------
> {a,NULL}
> (1 row)
Right, I will fix that.

> 2) Changing from returning arrays of primitive types to arrays of
> objects is necessary for null and multi-dimension support, but will
> still break users code all over the place. Not sure what we can do
> about that other than put a strong warning in the release notes.
For sure BC is important issue and maybe I should check PG version and
if it is < 8.2 then primitive arrays should be returned (just like
before - it needs only more code, but won't break current applications) ?

> 3) A lot of the code doesn't look like it handles multiple dimensions.
> What about things like fillIntegerResultSet? No that we're dealing with
> objects can't we abstract a lot of these copies away and provide one
> implementation that is multi-dimension aware? If you do
> Array.getResultSet you should be able to call ResultSet.getArray and the
> getResultSet on that, right?
Currently my patch applies only to java.sql.Array.getArray() and because
I didn't know what is your opinion about my implementation I didn't
patch any other methods (like java.sql.Array.getResultSet()). If you say
that my implementation + fixes proposed above are OK then I will make a
patch for other methods in order to provide full support of
java.sql.Array. Methods from AbstractJdbc2Array (like
fillIntegerResultSet()) either will be removed or fixed in order to work
with all those changes.

Best wishes,
Marek




---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Oliver Jowett pisze:
> I was wondering which behaviour was right -- I thought returning
> array-of-primitive was correct per the spec at the time I wrote it, and
> that's why getArray() returns Object not Object[] -- but now the 1.6
> javadoc says:
>
>> Note: When getArray is used to materialize a base type that maps to a
>> primitive data type, then it is implementation-defined whether the
>> array returned is an array of that primitive data type or an array of
>> Object.
>
> So I suppose that .. in theory .. applications should be expecting to
> handle both. Ugh.
My opinion is that we should keep BC either by building two different
jdbc versions or checking PG version every time getArray() is used (if <
8.2 then primitive types are used, if >= 8.2 then objects). Second
option is quite good, although it doesn't guaranty full BC - let assume
that someone is using jdbc application that was written for pg 8.0, but
after update to 8.2 the code with following statement:
<code>(boolean[]) getArray()</code>
would cause cast exception (Cannot cast from Boolean[] to boolean[]).

Regards,
ML





---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Marek Lewczuk wrote:

> My opinion is that we should keep BC either by building two different
> jdbc versions or checking PG version every time getArray() is used (if <
> 8.2 then primitive types are used, if >= 8.2 then objects).

Use the "compatible" URL option to make this decision, rather than
server version (there are some helper functions around to help here)

-O

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Oliver Jowett pisze:
> Use the "compatible" URL option to make this decision, rather than
> server version (there are some helper functions around to help here)
I will, thanks.

Marek



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings