Re: array support patch phase 1 patch

Peter Eisentraut wrote:
> Joe Conway writes:
>>    ...etc up to 6 dimensions
>
> Why only 6?

As Tom mentioned MAXDIM is currently set to 6. I can't imagine many
people using anything over 3 or maybe 4 dimensions.

>>4. Duplicated contrib/array functionality (and then some) in the
>>    backend using polymorphic functions and operators.
>
>>    SELECT ARRAY[1,2,3] *= 2 AS "TRUE";
>>    SELECT ARRAY[1,2,3] *<> 4 AS "TRUE";
>
> Couldn't this kind of operation be handled more cleanly (at least
> semantically speaking), if we provide a function that converts an array to
> a set and then use standard set searching operations?  For example,
>
> SELECT 2 IN TABLE(ARRAY[1,2,3]);

I thought about that too. It wouldn't be general enough to handle other
operators though, so I decided to stick with the already somewhat
established contrib/array operators. It sounds like Tom has some
concerns with those anyway, so in the meantime I'll take another look at
SQL200x to see if this is covered somewhere.


>>5. Side note: I added ANYARRAY1 and ANYELEMENT1 in this version.
>
> Doing what?

As I said:
  " I needed ANYARRAY1 for polymorphic array coercion, but did not add
    support for it to be used in any other way. I added ANYELEMENT1
    only for symmetry, and did not use it at all."

The problem lies in that fact that more than one reference to ANYARRAY
in the argument list of a function implies that the said arrays are all
the same data type. This doesn't work for a coercion function where you
need two array arguments, of arbitrary types, but that are not the same
as each other. I could not see any other clean way to achieve this.

I specifically did not add any other support for these data types
because there is not yet a strong case that user defined functions need
this capability. Of course if there is a strong feeling that they should
have full fledged support similar to ANYARRAY and ANYELEMENT, I'll
gladly add it.

Joe