From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Georgios <gkokolatos(at)protonmail(dot)com>, Asim Praveen <pasim(at)vmware(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [PATCH] - Provide robust alternatives for replace_string |
Date: | 2020-09-05 22:42:16 |
Message-ID: | 1315832.1599345736@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Note that starting with commit 67a472d71c98 you can use pg_get_line and
> not worry about the hard part of this anymore :-)
pg_get_line as it stands isn't quite suitable, because it just hands
back a "char *" string, not a StringInfo that you can do further
processing on.
However, I'd already grown a bit dissatisfied with exposing only that
API, because the code 8f8154a50 added to hba.c couldn't use pg_get_line
either, and had to duplicate the logic. So the attached revised patch
splits pg_get_line into two pieces, one with the existing char * API
and one that appends to a caller-provided StringInfo. (hba.c needs the
append-rather-than-reset behavior, and it might be useful elsewhere
too.)
While here, I couldn't resist getting rid of ecpg_filter()'s hard-wired
line length limit too.
This version looks committable to me, though perhaps someone has
further thoughts?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
v5-0001-use-stringinfo-for-replace_string.patch | text/x-diff | 13.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2020-09-05 23:20:42 | Re: WIP: BRIN multi-range indexes |
Previous Message | Justin Pryzby | 2020-09-05 21:06:58 | Re: v13: show extended stats target in \d |