PostgreSQL bug with array field

[Fr0sT]

@marsupilami: I personally see no sense in working on a half-dead feature... Honestly I have little exp with real DBs designed by someone else but I've never seen array fields mentioned in FB's forum topics. Moreover, easy array API could do a bad service to users hiding expensive BLOB operations. Just my humble 2 knuts

[stoffman]

I don't think it is half dead. As I've seen many cases of these none trivial types.

That being said, and considering the constrains of resources zeos have I think that converting them to strings is acceptable approach (in binary mode) something I'm working on. But it will take time...

[marsupilami]

I don't think it is half dead. As I've seen many cases of these none trivial types.

I think that even if it is rarely used, Zeos should strive to support what databases can do. The only question is which priority array support should have. My focus currently is on fixing bugs and improving the webservice driver.

That being said, and considering the constrains of resources zeos have I think that converting them to strings is acceptable approach (in binary mode) something I'm working on. But it will take time...

If you have working code, I am willing to include it. We also could add a branch for your work on our subversion repository. If you have questions, please let me know, I will answer them to my knowledge.
If you submit patches. I prefer smaller patches with a limited scope over big patches. This makes tracking down the sources of problems more easy when running these things through the test suites.

[Fr0sT]

As I've seen many cases of these none trivial types.

I'm not claiming to be absolutely right in any way. Would be nice if you provide some samples of array fields in real world

[stoffman]

I'm not sure what to tell you, I ran into this problem because I live in the real world

But fundamentally speaking, every object that is made out of series of primitives is a good candidate for an array. A "polygon" is a good example, as it described as a series of points on the plain. Normalize it as 2 tables with 1:N relation is just plain wrong.

[Fr0sT]

Unless you operate the polygon points from SQL, that polygon for database is just a single entity "polygon". So the only difference from, say, varbinary is a little bit shorter code at the client-side.

[marsupilami]

Unless you operate the polygon points from SQL, that polygon for database is just a single entity "polygon". So the only difference from, say, varbinary is a little bit shorter code at the client-side.

Having some support for arrays allows Zeos to display the information with a bit of structure.
"[[4, 5, 6][7, 8, 9]]"
might be more easily understandable to a user than
"00 00 00 02 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09"
Which might be a valid description for an array of integer data - or just some more or less random binary data.

Also I don't think that we should decide for users what they have to use or not. If somebody wants to provide a working implementation for Zeos, I will gladly accept it because it allows zeos to be used in an even wider range of use cases than before. Isn't that what OSS is about?

[Fr0sT]

If somebody wants to provide a working implementation for Zeos, I will gladly accept it because it allows zeos to be used in an even wider range of use cases than before. Isn't that what OSS is about?

THAT'S the point!! The key words here are "if wants to provide".