From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Implicit casts with generic arrays |
Date: | 2007-06-06 17:37:55 |
Message-ID: | 4666F0F3.4060107@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> Tom Lane wrote:
>>> In the long run maybe we should choose some other name for the
>>> array_append and array_prepend operators to avoid the confusion with
>>> concatenation. It seems to me that "concatenation" normally implies
>>> "stringing together similar objects", which these two operators
>>> definitely don't do, and so you could argue that || was a bad name
>>> for them from the get-go.
>
>> Originally I saw this situation as as requiring the concatenation
>> operator per SQL 2003:
>
> Maybe I am missing something, but the only such construct I see in
> SQL2003 is concatenation of arrays of equal rank. There is nothing
> corresponding to array_prepend or array_append.
Well, I've never claimed to be particularly good at interpreting the SQL
spec, but as an example...
<array concatenation> ::=
<array value expression 1> || <array primary>
<array primary> ::=
<value expression primary> ::=
<nonparenthesized value expression primary> ::=
<unsigned value specification> ::=
<unsigned literal> ::=
<unsigned numeric literal>
Doesn't this mean that array concatenation should include things like:
<array value expression> || <unsigned numeric literal>
e.g.
ARRAY[1,2,3] || 42
?
> I do have a plan B if people don't want to rename the operators, though.
> It looks to me like we could eliminate the conflict if we invented a new
> polymorphic pseudotype called "anynonarray" or some such, which would
> act like anyelement *except* it would not match an array. Then,
> declaring the capturing operators as text||anynonarray and
> anynonarray||text would prevent them from matching any case where either
> side was known to be an array type. But they would (I think) still win
> out in cases such as scalar || 'unknown literal'. The end result would
> be that concatenations involving a known-array value would be array
> concatenation, but you could force them to be text concatenation, if
> that's what you wanted, by explicitly casting the array value(s) to text.
That sounds reasonable to me.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2007-06-06 18:05:35 | Re: Controlling Load Distributed Checkpoints |
Previous Message | Florian G. Pflug | 2007-06-06 17:25:52 | Re: [RFC] GSoC Work on readonly queries done so far |