Re: pipe_read_line for reading arbitrary strings

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pipe_read_line for reading arbitrary strings
Date: 2023-09-25 07:55:36
Message-ID: 43F14E00-A001-4232-9BE8-A8C945B1B194@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 4 Jul 2023, at 14:50, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 4 Jul 2023, at 13:59, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> On 08/03/2023 00:05, Daniel Gustafsson wrote:
>
>>> If we are going to continue using this for reading $stuff from pipes, maybe we
>>> should think about presenting a nicer API which removes that risk? Returning
>>> an allocated buffer which contains all the output along the lines of the recent
>>> pg_get_line work seems a lot nicer and safer IMO.
>>
>> +1
>
> Thanks for review!
>
>>> /*
>>> * Execute a command in a pipe and read the first line from it. The returned
>>> * string is allocated, the caller is responsible for freeing.
>>> */
>>> char *
>>> pipe_read_line(char *cmd)
>>
>> I think it's worth being explicit here that it's palloc'd, or malloc'd in frontend programs, rather than just "allocated". Like in pg_get_line.
>
> Good point, I'll make that happen before committing this.

Fixed, along with commit message wordsmithing in the attached. Unless objected
to I'll go ahead with this version.

--
Daniel Gustafsson

Attachment Content-Type Size
v3-0001-Refactor-pipe_read_line-to-return-the-full-line.patch application/octet-stream 6.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2023-09-25 08:33:41 Re: [PoC] pg_upgrade: allow to upgrade publisher node
Previous Message Laurenz Albe 2023-09-25 07:54:22 Regression in COPY FROM caused by 9f8377f7a2