Re: multiset patch review

Поиск
Список
Период
Сортировка
От Itagaki Takahiro
Тема Re: multiset patch review
Дата
Msg-id AANLkTimj6WQeR+Vbop_nVG8nQd_m1hAyVUv0OdPCSgTq@mail.gmail.com
обсуждение исходный текст
Ответ на Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: multiset patch review  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jan 31, 2011 at 02:34, Robert Haas <robertmhaas@gmail.com> wrote:
>>> I'm in favor of rejecting this patch in its entirety.  The
>>> functionality looks useful, but once you remove the syntax support, it
>>> could just as easily be distributed as a contrib module rather than in
>>> core.
>>
>> +1 ... if we're going to provide nonstandard behavior, it should be with
>> a different syntax.  Also, with a contrib module we could keep on
>> providing the nonstandard behavior for people who still need it, even
>> after implementing the standard properly.
>
> Good point.

I agree for collect() function, that is the only function we cannot
provide compatibility when we have MULTISET. But others are still
reasonable because they won't provide nonstandard behavior.

The SQL standard seems to have abstract COLLECTION data type as a
super class of ARRAY and MULTISET. So, it's reasonable that
functions and operators that accept MULTISETs also accept ARRAYs.
For example, we will have cardinality(ARRAY) even if we have
cardinality(MULTISET). Also, trim_array() is in the SQL standard.

I can remove some parts in the patch, especially for parser changes,
but others should be still in the core.

--
Itagaki Takahiro


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joachim Wieland
Дата:
Сообщение: Re: Snapshot synchronization, again...
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: REVIEW: Determining client_encoding from client locale