Re: Replace open mode with PG_BINARY_R/W/A macros

From: Japin Li <japinli(at)hotmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Replace open mode with PG_BINARY_R/W/A macros
Date: 2022-04-19 05:29:18
Message-ID: MEYP282MB1669DC0E5BC52C61EF96072FB6F29@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Mon, 18 Apr 2022 at 22:41, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Japin Li <japinli(at)hotmail(dot)com> writes:
>> I found we defined PG_BINARY_R/W/A macros for opening files, however,
>> there are some places use the constant strings. IMO we should use
>> those macros instead of constant strings. Here is a patch for it.
>> Any thoughts?
>
> A lot of these changes look wrong to me: they are substituting "rb" for
> "r", etc, in places that mean to read text files. You have to think
> about the Windows semantics.
>

I do this substituting, since the comment says it can be used for opening
text files. Maybe I misunderstand the comment.

/*
* NOTE: this is also used for opening text files.
* WIN32 treats Control-Z as EOF in files opened in text mode.
* Therefore, we open files in binary mode on Win32 so we can read
* literal control-Z. The other affect is that we see CRLF, but
* that is OK because we can already handle those cleanly.
*/
#if defined(WIN32) || defined(__CYGWIN__)
#define PG_BINARY O_BINARY
#define PG_BINARY_A "ab"
#define PG_BINARY_R "rb"
#define PG_BINARY_W "wb"
#else
#define PG_BINARY 0
#define PG_BINARY_A "a"
#define PG_BINARY_R "r"
#define PG_BINARY_W "w"
#endif

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2022-04-19 05:29:56 Re: A qsort template
Previous Message Michael Paquier 2022-04-19 05:19:45 Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths