Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

2017-04-09 Thread David E. Wheeler
On Apr 9, 2017, at 9:59 PM, Andrew Gierth wrote: > Tom's response has the explanation of why it fails (everywhere, not just > in the exception block): parse analysis prefers to match the (array || > array) form of the operator when given input of (array || unknown).

Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

2017-04-09 Thread Andrew Gierth
> "David" == David E Wheeler writes: >> If you change this to EXCEPTION WHEN division_by_zero THEN, the >> reported error becomes: >> >> ERROR: malformed array literal: "foo" >> LINE 1: SELECT things || 'foo' David> So the issue stands, yes? Tom's response

Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

2017-04-09 Thread David E. Wheeler
On Apr 9, 2017, at 9:52 PM, Andrew Gierth wrote: > This "raise" statement is not reached, because the previous line raises > the "malformed array literal" error. Bah! > David> EXCEPTION WHEN OTHERS THEN > > If you change this to EXCEPTION WHEN

Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

2017-04-09 Thread Andrew Gierth
> "David" == David E Wheeler writes: David> And it works great, including in PL/pgSQL functions, except in David> an exception block. When I run this: David> BEGIN; David> CREATE OR REPLACE FUNCTION foo( David> ) RETURNS BOOLEAN IMMUTABLE LANGUAGE

Re: [HACKERS] Malformed Array Literal in PL/pgSQL Exception Block

2017-04-09 Thread Tom Lane
"David E. Wheeler" writes: > I’ve been happily using the array-to-element concatenation operator || to > append a single value to an array, e.g, > SELECT array || 'foo'; > And it works great, including in PL/pgSQL functions, except in an > exception block. Hm,