From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Subject: | Re: multiset patch review |
Date: | 2011-02-05 02:11:22 |
Message-ID: | AANLkTi=vJ6DDSDs6BUECzKnx8Xy1AMsd3KCHgL7FN5UW@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
>> In math class, maybe. But in programming, no. Multiset is a
>> datatype. Array is a different datatype. There is no reason why we
>> need to clutter our parser with extra keywords to support a
>> non-standard feature extension.
>
> My understanding is that we will have to have those functions defined
> and user visible, and that we benefit from function overloading which is
> not in the standard. So there's no reason not to provide those function
> for arrays already, then extend to full multiset support.
>
> Given PostgreSQL overloading, yes, arrays are multisets as far as
> defining those standard compliant APIs is concerned. AFAIUI.
Yes, I'd like to use overloading.
Choosing arbitrary names increases learning costs for users.
--
Itagaki Takahiro
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2011-02-05 02:15:04 | Re: Named restore points |
Previous Message | Mark Mielke | 2011-02-05 01:50:13 | Re: Does auto-analyze work on dirty writes? |