Re: Replace open mode with PG_BINARY_R/W/A macros - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Replace open mode with PG_BINARY_R/W/A macros
Date
Msg-id 2993591.1650486568@sss.pgh.pa.us
Whole thread Raw
In response to Re: Replace open mode with PG_BINARY_R/W/A macros  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Replace open mode with PG_BINARY_R/W/A macros  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 19.04.22 16:21, Tom Lane wrote:
>> * In the other direction, decide that the PG_BINARY_X macros are
>> offering no benefit at all and just rip 'em out, writing "rb" and
>> so on in their place.  POSIX specifies that the character "b" has
>> no effect on Unix-oid systems, and it has said that for thirty years
>> now, so we do not really need the platform dependency that presently
>> exists in the macro definitions.  The presence or absence of "b"
>> would serve fine as an indicator of intent, and there would be one
>> less PG-specific coding convention to remember.

> I can only imagine that there must have been some Unix systems that did 
> not understand the "binary" APIs required for Windows.  (For example, 
> neither the Linux nor the macOS open(2) man page mentions O_BINARY.) 
> Otherwise, these macros don't make any sense, because then you could 
> just write the thing directly on all platforms.

PG_BINARY is useful for open().  It's the PG_BINARY_R/W/A macros for
fopen() that are redundant per POSIX.  Possibly someone generalized
inappropriately; or maybe long ago we supported some platform that
rejected the "b" option?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: when should we set DB_IN_PRODUCTION?
Next
From: Thomas Munro
Date:
Subject: Re: pg14 psql broke \d datname.nspname.relname