Re: array support patch phase 1 patch

Peter Eisentraut wrote:
[...much snipping follows...]
> No, the analogues would be "unidimensional", "bidimensional", and
> "many-dimensional". There difference is that you close up prefixes (which
> are not words by themselves), but you hyphenate compounds of independent
> words.
>
>>>The function array_subscript() should be removed from code and
>>>The function array_assign() should be removed from code and documentation.
>>>The function singleton_array() should be removed from code and
>>
>>>The function array_append() should be documented as being equivalent to
>>>'array || element' and specifically intended for user-defined aggregate
>>>functions.
>>
>>That's fine. I would add similar descriptions for array_prepend() and
>>array_cat().
>
> Sounds good. My main concern is that people will have a clear view of
> what's standard and recommended for which situation, so that support will
> be easier and users won't be confronted with a long list of equivalent,
> undifferentiated options.
>

The attached patch addresses Peter's concerns, subject to our agreements
above. I.e, the changes are:

1) All instances of "multi-dimensional array" and "multiple dimension
array" throughout the source tree have been changed to "multidimensional
array". Even if everyone doesn't agree this is correct, it is at least
consistent throughout, so if we later decide to change it back, it will
be easier ;-)

2) The functions singleton_array(), array_assign(), and
array_subscript() have been removed along with all references thereof.

3) The documentation emphasizes use of the concatenation operator '||'
as preferred over the functions array_append(), array_prepend(), and
array_cat(). A mention of direct use of the functions in user-defined
aggregates is also included.

[...more snipage from a different part of the thread...]
Tom Lane wrote:
> BTW, it might be better for array_cmp to insist that the array element
> type have a default btree opclass, and use the comparison proc from
> that opclass in place of equality_oper() and ordering_oper(). This'd
> be faster (only one call per comparison) as well as more semantically
> pure.

I stopped short of this change because there doesn't seem to be a way to
get the btree opclass tuple given just the opcintype without scanning
pg_opclass. Am I missing something? Or should I just not worry about it
and scan pg_opclass?

> I've got some other problems with this patch (I still don't understand
> what the hacking on aggregates is supposed to accomplish, for example)
> but the array comparison stuff seems relatively straightforward.

As I said in an earlier message, I believe that I have implemented this
correctly. Is there a specific corner case not covered? I'd really like
to see some form of polymorphic function support for aggregates --
please let me know what I can do to make that happen.

Joe

p.s. I added Bruce to the thread because he asked me about the status of
the patch, and because the lists have been so slow the last few days.