Re: Inconvenience of pg_read_binary_file()

At Tue, 7 Jun 2022 16:33:53 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Tue, Jun 07, 2022 at 04:05:20PM +0900, Kyotaro Horiguchi wrote:
> > If I want to read a file that I'm not sure of the existence but I want
> > to read the whole file if exists, I would call
> > pg_read_binary_file('path', 0, -1, true) but unfortunately this
> > doesn't work.
> 
> Yeah, the "normal" cases that I have seen in the past just used an
> extra call to pg_stat_file() to retrieve the size of the file before
> reading it, but arguably it does not help if the file gets extended
> between the stat() call and the read() call (we don't need to care
> about this case with pg_rewind that has been the reason why the
> missing_ok argument was introduced first, for one, as file extensions
> don't matter as we'd replay from the LSN point where the rewind
> began, adding the new blocks at replay).

Sure.

> There is also an argument for supporting negative values rather than
> just -1.  For example -2 could mean to read all the file except the
> last byte.  Or you could have an extra flavor, as of
> pg_read_file(text, bool) to read the whole by default.  Supporting
> just -1 as special value for the amount of data to read would be
> confusing IMO.  So I would tend to choose for a set of arguments based
> on (text, bool).

I'm not sure about the negative length smaller than -1, since I don't
find an apprpriate offset that represents (last byte + 1).

pg_read_file(text, bool) makes sense to me, but it doesn't seem like
to be able to share C function with other variations.
pg_read_binary_file() need to accept some out-of-range value for
offset or length to signal that offset and length are not specified.

In the attached pg_read(_binary)_file_all() is modifiedf so that they
have the different body from pg_read(_binary)_file().

(function comments needs to be edited and docs are needed)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center