Re: array support patch phase 1 patch

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: array support patch phase 1 patch
Дата
Msg-id Pine.LNX.4.44.0306061609410.1848-100000@peter.localdomain
обсуждение исходный текст
Ответ на array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
Ответы Re: array support patch phase 1 patch  (Joe Conway <mail@joeconway.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Removing a user's password
Следующее
От: Rod Taylor
Дата:
Сообщение: Fix up JOIN .. USING with domains