Re: Surprising results from array concatenation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Surprising results from array concatenation
Date: 2017-04-25 17:53:17
Message-ID: 24303.1493142797@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Tue, Apr 25, 2017 at 9:26 AM, Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>
> wrote:
>> The docs (section 9.18 for PG 9.6) show as an example for array
>> concatenation
>> ARRAY[4,5,6] || 7
>> which works fine. However, trying the same with an array of text doesn't
>> work:
>> # select array['a','b','c'] || 'd';
>> ERROR: malformed array literal: "d"
>>
>> The assumption that the second argument is an array constant seems
>> surprising

> ​It has to assume something. And for better and worse it has to assume it
> without looking at the actual value.

Yeah. The core problem here is that the parser has to disambiguate the
|| operator: is it "anyarray || anyelement" or "anyarray || anyarray"?
In your first example the array can be seen to be int[] and 7 is taken
to be type int, so only "anyarray || anyelement" works. In the second
case it's looking at "int[] || unknown", and the relevant heuristic is
to assume that the "unknown" is the same type as the operator's other
input.

Peeking at the contents of the literal would make the behavior very
unpredictable/data-dependent, so we don't.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Blackwell 2017-04-25 18:23:14 Re: Surprising results from array concatenation
Previous Message David G. Johnston 2017-04-25 16:41:30 Re: Surprising results from array concatenation