| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Lift line-length limit for pg_service.conf |
| Date: | 2020-09-22 22:09:55 |
| Message-ID: | 1337964.1600812595@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> On 22 Sep 2020, at 23:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> In the same vein, here's a patch to remove the hard-coded line length
>> limit for tsearch dictionary files.
> LGTM. I like the comment on why not to return buf.data directly, that detail
> would be easy to miss.
Yeah. In a quick scan, it appears that there is only one caller that
tries to save the result directly. So I considered making that caller
do a pstrdup and eliminating the extra thrashing in t_readline itself.
But it seemed too fragile; somebody would get it wrong and then have
excess space consumption for their dictionary.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2020-09-22 23:18:51 | Re: new heapcheck contrib module |
| Previous Message | Peter Eisentraut | 2020-09-22 21:45:14 | Re: Range checks of pg_test_fsync --secs-per-test and pg_test_timing --duration |