Tom Lane wrote:


The expressions
'abc' || 34
34 || 'abc'
would no longer work, with the following error message:
ERROR:  22P02: array value must start with "{" or dimension information

Hm, that's annoying.  Not that the expressions fail --- we want them to
--- but that the error message is so unhelpful.

indeed

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.  But compatibility worries would mean we
couldn't eliminate the old names for quite a long time, so maybe
it's too late for that.

Comments?

Originally I saw this situation as as requiring the concatenation operator per SQL 2003:

<array value expression> ::=
    <array concatenation>
  | <array primary>
<array concatenation> ::=
   <array value expression 1> <concatenation operator> <array primary>
<concatenation operator> ::= ||

<array value expression 1> ::= <array value expression>
<array primary> ::= <value expression primary>
<value expression primary> ::=
    <parenthesized value expression>
  | <nonparenthesized value expression primary>
<parenthesized value expression> ::=
    <left paren> <value expression> <right paren>
<value expression> ::=
    <common value expression>
  | <boolean value expression>
  | <row value expression>
<common value expression> ::=
    <numeric value expression>
  | <string value expression>
  | <datetime value expression>
  | <interval value expression>
  | <user-defined type value expression>
  | <reference value expression>
  | <collection value expression>
<nonparenthesized value expression primary> ::=
    <unsigned value specification>
  | <column reference>
  | <set function specification>
  | <window function>
  | <scalar subquery>
  | <case expression>
  | <cast specification>
  | <field reference>
  | <subtype treatment>
  | <method invocation>
  | <static method invocation>
  | <new specification>
  | <attribute or method reference>
  | <reference resolution>
  | <collection value constructor>
  | <array element reference>
  | <multiset element reference>
  | <routine invocation>
  | <next value expression>
<collection value constructor> ::=
    <array value constructor>
  | <multiset value constructor>
<unsigned value specification> ::=
    <unsigned literal>
  | <general value specification>
<unsigned literal> ::=
    <unsigned numeric literal>
  | <general literal>
<general literal> ::=
    <character string literal>
  | <national character string literal>
  | <Unicode character string literal>
  | <binary string literal>
  | <datetime literal>
  | <interval literal>
  | <boolean literal>


What I can't decide now is whether all the above means the anyelement in this operation ought to be in parens or not. It seems to me that the anyelement can be any literal _except_ a <signed numeric literal>. In that case the spec seems to require parenthesis.

Joe

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to