Re: BUG #16688: psql removes only LF without CR at end of backquotes on windows. - Mailing list pgsql-bugs

From Bruce Momjian
Subject Re: BUG #16688: psql removes only LF without CR at end of backquotes on windows.
Date
Msg-id 20201028204654.GD3239@momjian.us
Whole thread Raw
In response to Re: BUG #16688: psql removes only LF without CR at end of backquotes on windows.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Wed, Oct 28, 2020 at 02:39:39PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Tue, Oct 27, 2020 at 11:27:05PM -0400, Tom Lane wrote:
> >> But rather than mess with that newline-chomping code, I'm
> >> inclined to wonder why we're using PG_BINARY_R for input
> >> that we clearly expect to be textual.  Most of our other
> >> popen's do not do that.
> >> 
> >> Bruce, this seems to date to 98e9775a3 ... don't suppose
> >> you remember that?  I see the point about control-Z in text
> >> files, but I wonder how plausible that is for popen cases.
> 
> > It seems safe for popen to use TEXT mode, and it might help with
> > encoding conversion.  I don't think I made a popen distinction when I
> > was working in this area.
> 
> I double-checked, and verified that our only other popen() calls
> that use binary mode are dealing with COPY data.  It seems appropriate
> to do so in that case, partly because the data might indeed be binary
> and partly because we have adequate newline recognition logic in copy.c.
> But it does seem best to uniformly use plain "r" or "w" for other
> popen's.  So I've fixed this that way.

Thanks.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16688: psql removes only LF without CR at end of backquotes on windows.
Next
From: Wolfgang Walther
Date:
Subject: Calling variadic function with default value in named notation