Re: [PATCH] - Provide robust alternatives for replace_string

Asim Praveen <pasim@vmware.com>

From: Asim Praveen <pasim@vmware.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Georgios <gkokolatos@protonmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-08-05T07:08:41Z
Lists: pgsql-hackers

Attachments

> On 03-Aug-2020, at 8:36 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> 
> On 2020-Aug-03, Asim Praveen wrote:
> 
>> Thank you Alvaro for reviewing the patch!
>> 
>>> On 01-Aug-2020, at 7:22 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>> 
>>> What happens if a replacement string happens to be split in the middle
>>> by the fgets buffering?  I think it'll fail to be replaced.  This
>>> applies to both versions.
>> 
>> Can a string to be replaced be split across multiple lines in the source file?  If I understand correctly, fgets reads one line from input file at a time.  If I do not, in the worst case, we will get an un-replaced string in the output, such as “@abs_dir@“ and it should be easily detected by a failing diff.
> 
> I meant what if the line is longer than 1023 chars and the replace
> marker starts at byte 1021, for example.  Then the first fgets would get
> "@ab" and the second fgets would get "s_dir@" and none would see it as
> replaceable.
> 


Please find attached a StringInfo based solution to this problem.  It uses fgetln instead of fgets such that a line is read in full, without ever splitting it.

Asim

Commits

  1. Refactor pg_get_line() to expose an alternative StringInfo-based API.

  2. Remove arbitrary line length limits in pg_regress (plain and ECPG).

  3. Remove arbitrary restrictions on password length.