Peter Eisentraut <peter_e@gmx.net> writes:
> Joe Conway writes:
>> ...etc up to 6 dimensions
> Why only 6?
See uses of MAXDIM. If you feel that 6 isn't enough, I wouldn't have
a problem with raising MAXDIM to 10 or so. I don't think it's worth
trying to eliminate the limit completely; that would add palloc overhead
to every array operation, for a feature people are unlikely to use.
>> 4. Duplicated contrib/array functionality (and then some) in the
>> backend using polymorphic functions and operators.
> 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]);
Not sure about that. Is there any guidance in the SQL 200x spec about
what they expect people to actually *do* with the ARRAY[] syntax?
I'm currently working over the patch, but am not going to commit this
part (yet), since I have some problems with the implementation anyway.
>> 5. Side note: I added ANYARRAY1 and ANYELEMENT1 in this version.
> Doing what?
I'm hoping to avoid committing those, as they don't seem to be
completely implemented in this patch. They may be required to
represent the behavior of array_coerce() though. Not sure yet.
regards, tom lane