From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Subject: | Re: File* argument order, argument types |
Date: | 2023-02-20 13:48:01 |
Message-ID: | 5da34321-9503-128b-f646-1c2cecf0516a@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18.02.23 01:52, Andres Freund wrote:
> I don't know what to actually propose. I guess the least bad I can see is to
> pick one type & argument order that we document to be the default, with a
> caveat placed above the functions not following the argument order.
>
> Order wise, I think we should choose amount, offset. For the return type we
> probably should pick ssize_t? I don't know what we should standardize on for
> 'amount', I'd probably be inclined to go for size_t.
This reminds me that most people talk about LIMIT X OFFSET Y, even
though what actually happens is that the offset is handled first and
then the limit is applied. This is also reflected in the standard SQL
spelling OFFSET Y FETCH FIRST Z ROWS, in that order. So, just saying
that there is universal disagreement on the order of these things.
I think the correct order is offset, then amount. And I think the OS C
APIs mostly agree with that, if you look at the newer ones. The
exceptions are the likes of pread() and pwrite(); I think they just kept
the signature of read() and write() and added the additional offset
argument at the end, which I think is a sensible compromise.
For the proposed FileFallocate() I would therefore also keep the order
of posix_fallocate(), so it would be
FileFallocate(File file, off_t offset, off_t len, ...)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2023-02-20 14:03:52 | Re: some namespace.c refactoring |
Previous Message | gkokolatos | 2023-02-20 13:09:22 | Re: Add LZ4 compression in pg_dump |