Re: Implicit casts with generic arrays
От | Joe Conway |
---|---|
Тема | Re: Implicit casts with generic arrays |
Дата | |
Msg-id | 4666F0F3.4060107@joeconway.com обсуждение исходный текст |
Ответ на | Re: Implicit casts with generic arrays (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Implicit casts with generic arrays
|
Список | 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 по дате отправления: