Re: pipe_read_line for reading arbitrary strings

Daniel Gustafsson <daniel@yesql.se>

From: Daniel Gustafsson <daniel@yesql.se>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Peter Eisentraut <peter@eisentraut.org>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-03-06T10:49:00Z
Lists: pgsql-hackers
> On 6 Mar 2024, at 11:46, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 
> On 2024-Mar-06, Daniel Gustafsson wrote:
> 
>> Good catch, that's an incorrect copy/paste, it should use ERRCODE_NO_DATA.  I'm
>> not convinced that a function to read from a pipe should consider not reading
>> anything successful by default, output is sort expected here.  We could add a
>> flag parameter to use for signalling that no data is fine though as per the
>> attached (as of yet untested) diff?
> 
> I think adding dead code is not a great plan, particularly if it's hairy
> enough that we need to very carefully dissect what happens in error
> cases.  IMO if and when somebody has a need for an empty return string
> being acceptable, they can add it then.

I agree with that, there are no callers today and I can't imagine one off the
cuff.  The change to use the appropriate errcode still applies though.

--
Daniel Gustafsson




Commits

  1. Fix errorhandling for reading from a pipe

  2. Refactor pipe_read_line to return the full line

  3. Add -c/--restore-target-wal to pg_rewind

  4. Here is a patch that fixes the pipes used in find_other_exec() when