Skip site navigation (1) Skip section navigation (2)

Re: Implicit casts with generic arrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
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 14:21:32
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

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.

I was a bit hesitant to propose this since I couldn't immediately think
of any other use-case for such a pseudotype.  It's not a huge amount of
added code (cf. anyenum) but it's definitely a visible wart on the type
system.  Comments?

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-06-06 14:36:59
Subject: Re: Implicit casts with generic arrays
Previous:From: Gregory StarkDate: 2007-06-06 14:14:14
Subject: Re: Controlling Load Distributed Checkpoints

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group