Re: Implicit casts with generic arrays - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Implicit casts with generic arrays
Date
Msg-id 4666F0F3.4060107@joeconway.com
Whole thread Raw
In response to Re: Implicit casts with generic arrays  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Implicit casts with generic arrays
List pgsql-hackers
Tom Lane wrote:
> Joe Conway <mail@joeconway.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



pgsql-hackers by date:

Previous
From: "Florian G. Pflug"
Date:
Subject: Re: [RFC] GSoC Work on readonly queries done so far
Next
From: Greg Smith
Date:
Subject: Re: Controlling Load Distributed Checkpoints