Re: [PATCH] - Provide robust alternatives for replace_string

Поиск
Список
Период
Сортировка
От Asim Praveen
Тема Re: [PATCH] - Provide robust alternatives for replace_string
Дата
Msg-id F57E6876-C6F0-4A4F-9F3E-F06F07A3803A@vmware.com
обсуждение исходный текст
Ответ на Re: [PATCH] - Provide robust alternatives for replace_string  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: [PATCH] - Provide robust alternatives for replace_string  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
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
oneline from input file at a time.  If I do not, in the worst case, we will get an un-replaced string in the output,
suchas “@abs_dir@“ and it should be easily detected by a failing diff.
 

> In the stringinfo version it seemed to me that using pnstrdup is
> possible to avoid copying trailing bytes.
> 

That’s a good suggestion.  Using pnstrdup would look like this:

--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -465,7 +465,7 @@ replace_stringInfo(StringInfo string, const char *replace, const char *replaceme

        while ((ptr = strstr(string->data, replace)) != NULL)
        {
-               char       *dup = pg_strdup(string->data);
+              char       *dup = pnstrdup(string->data, string->maxlen);
                size_t          pos = ptr - string->data;

                string->len = pos;

 
> If you're asking for opinion, mine is that StringInfo looks to be the
> better approach, and also you don't need to keep API compatibility.
> 

Thank you.  We also prefer StringInfo solution.

Asim

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Replication & recovery_min_apply_delay
Следующее
От: Ajin Cherian
Дата:
Сообщение: Re: deferred primary key and logical replication