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
|
Список | 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 по дате отправления: