From: | Vik Fearing <vik(at)postgresfriends(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dian M Fay <dian(dot)m(dot)fay(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: TRIM_ARRAY |
Date: | 2021-03-03 22:03:46 |
Message-ID: | 5d4074b7-f844-e52c-2b3b-833f2d334a69@postgresfriends.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2021-03-03 22:10:50 | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |
Previous Message | Tom Lane | 2021-03-03 21:47:17 | Re: TRIM_ARRAY |