Re: Implicit casts with generic arrays

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

In response to

Responses

Browse pgsql-hackers by date

  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