Re: [PATCH] - Provide robust alternatives for replace_string - Mailing list pgsql-hackers

From Asim Praveen
Subject Re: [PATCH] - Provide robust alternatives for replace_string
Date
Msg-id FD546689-FA22-4605-98AB-4A8AA95DFF76@vmware.com
Whole thread Raw
In response to Re: [PATCH] - Provide robust alternatives for replace_string  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [PATCH] - Provide robust alternatives for replace_string
List pgsql-hackers
> 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
readsone 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
readin full, without ever splitting it.
 

Asim


Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: LSM tree for Postgres
Next
From: Konstantin Knizhnik
Date:
Subject: Re: LSM tree for Postgres