Re: array support patch phase 1 patch - Mailing list pgsql-patches

From Peter Eisentraut
Subject Re: array support patch phase 1 patch
Date
Msg-id Pine.LNX.4.44.0306061609410.1848-100000@peter.localdomain
Whole thread Raw
In response to array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
Responses Re: array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
List pgsql-patches
Joe Conway writes:

> And if you use "multidimensional", does that mean you also use
> "onedimensional" and "twodimensional", etc.?

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
>
> I still have an uneasy feeling that there are situations where your only
> option to get this functionality is via a function call.

Once that feeling materializes into a real concern, we can still consider
action.  Maybe there will at some point be a need for these functions, but
maybe we will need a similar function with slightly different
functionality, or whatever.  Hard to tell as long as we're fantasizing.

> I've heard no one else vote to remove them.

Was there ever a vote to add them?

> > The functions array_prepend() and array_cat() should be removed from the
> > documentation and considered internal implementations of the operator ||.
>
> I disagree with this one. Both array_prepend() and array_cat() have
> valid use in aggregates.

> > 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.

--
Peter Eisentraut   peter_e@gmx.net


pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Removing a user's password
Next
From: Rod Taylor
Date:
Subject: Fix up JOIN .. USING with domains