Re: SQL99 ARRAY support proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SQL99 ARRAY support proposal
Date
Msg-id 9271.1047589432@sss.pgh.pa.us
Whole thread Raw
In response to Re: SQL99 ARRAY support proposal  (Hannu Krosing <hannu@tm.ee>)
List pgsql-hackers
Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane kirjutas N, 13.03.2003 kell 19:12:
>>> The standard spelling for that appears to be
>>> somearray || ARRAY[element]
>>> which also has the nice property that it is commutative.
>> 
>> Sure ... but that just means that || is the operator name for the
>> underlying array_push function.  We still need a way to declare this
>> operation as a function.

> I think he mant that you just need to conacat for too arrays, no need
> for single-element push/append.

Oh, I see.  But my point remains: unless you want to take || out of the
domain of operators and make it something hard-wired into the parser,
there has to be an underlying function with a matching signature.  So
all these problems come up anyway.

> contrib/intarray has the following functions (note that they use + for
> || above)

The reason that stuff is still contrib, and not mainstream, is we didn't
have a way to make the functions polymorphic.  One-datatype-at-a-time
interface functions are not appealing, especially not when they have to
be hand-coded in C.  But with the features discussed in this thread, we
could make the intarray functionality datatype-independent --- whereupon
I for one would vote to move it into the mainstream.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: SQL99 ARRAY support proposal
Next
From: Taral
Date:
Subject: No merge sort?