Re: [HACKERS] Indirect assignment code for array slices is dead code? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Indirect assignment code for array slices is dead code?
Date
Msg-id 20170311020303.qzb22f5jgo6yx35x@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Indirect assignment code for array slices is dead code?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2017-03-10 20:59:48 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > In the context of my expression evaluation patch, I was trying to
> > increase test coverage of execQual.c.  I'm a bit confused about
> > $subject.  ExecEvalArrayRef() has the following codepath:
> 
> I think it may indeed be unreachable at present, because we don't support
> something like this:
> 
> regression=# create table tt (f1 complex[]);
> CREATE TABLE
> regression=# update tt set f1[2:3].r = array[7,11];
> ERROR:  cannot assign to field "r" of column "f1" because its type complex[] is not a composite type
> LINE 1: update tt set f1[2:3].r = array[7,11];
>                       ^
> 
> regression=# update tt set f1[2:3].r = array[7,11];
> ERROR:  cannot assign to field "r" of column "f1" because its type complex[] is not a composite type
> LINE 1: update tt set f1[2:3].r = 42;

Yea, that's where I got too.


> I would not like to remove it though.  This particular bit of the executor
> has no business making assumptions about how array and field references
> can be nested.

Not planning to - I am just trying to make sure I get the corner cases
right - if there had been a way to reach that bit of code, I'd have like
to understand how, before screwing around.

Thanks for looking,

Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Indirect assignment code for array slices is dead code?
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Need a builtin way to run all tests faster manner