Subject: Re: TRIM_ARRAY
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Dian M Fay <dian.m.fay@gmail.com>, pgsql-hackers@lists.postgresql.org
References: <C9MFB04FWKBB.13JGHNUNS5Z4R@lamia>
 <6565ca98-6733-532a-2130-752545bab6b5@postgresfriends.org>
 <1249311.1614808037@sss.pgh.pa.us>
From: Vik Fearing <vik@postgresfriends.org>
Message-ID: <5d4074b7-f844-e52c-2b3b-833f2d334a69@postgresfriends.org>
Date: Wed, 3 Mar 2021 23:03:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <1249311.1614808037@sss.pgh.pa.us>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/5d4074b7-f844-e52c-2b3b-833f2d334a69%40postgresfriends.org>
Precedence: bulk

On 3/3/21 10:47 PM, Tom Lane wrote:
> 
> I had the same problem as Dian of the func.sgml hunk winding up in
> the wrong place.  I think this is practically inevitable unless the
> submitter uses more than 3 lines of context for the diff, because
> otherwise the context is just boilerplate that looks the same
> everywhere in the function tables.  Unless the diff is 100% up to date
> so that the line numbers are exactly right, patch is likely to guess
> wrong about where to insert the new hunk.  We'll just have to be
> vigilant about that.

Noted.

> I fooled with your test case a bit ... I didn't think it was really
> necessary to create and drop a table, when we could just use a VALUES
> clause as source of test data.  Also you'd forgotten to update the
> "descr" description of the function to match the final understanding
> of the semantics.

Thank you.

> Looks good otherwise, so pushed.

Thanks!
-- 
Vik Fearing