On Fri, Feb 4, 2011 at 9:11 PM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Sat, Feb 5, 2011 at 04:24, Dimitri Fontaine <dimitri@2ndquadrant.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.
Right, but making the parser slower has a cost, too.
ScanKeywordLookup() is already a hotspot in some workloads, and
there's overhead buried in the bison parser, too. I think it's a big
mistake to get into the business of adding keywords just so we can
provide an alternative syntax to call a function. Many people who use
these functions will never even have heard of the MULTISET stuff that
is part of the spec, and even those that have can figure out our
alternatives by spending five minutes with the documentation. I find
it really difficult to accept that it is worth slowing down parsing
for the 95% of users who are not going to use these functions to
provide a slightly nicer API for the ones that do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
