Re: smgrzeroextend clarification

I have committed some of the unrelated formatting changes separately, so
what's left now is attached.

On 17.05.23 01:38, Andres Freund wrote:
>> - I left this for smgrzeroextend():
>>
>> FIXME: why both blocknum and nblocks
>
> I guess you're suggesting that we would do an lstat() to figure out the size
> instead? Or use some cached size? That'd not be trivial to add - and it just
> seems unrelated to smgzerorextend(), it's just as true for smgrextend().

What smgzerorextend() does now seems sensible to me. I'd just like one
or two sentences that document its API. Right now, blocknum and nblocks
are not documented at all. Of course, we can guess, but I'm also
interested in edge cases. What are you supposed to pass for blocknum?
What happens if it's not right after the current last block? You
answered that, but is that just what happens to happen, or do we
actually want to support that? What happens if blocknum is *before* the
currently last block? Would that overwrite the last existing blocks
with zero? What if nblocks is negative? Does that zero out blocks
backwards?

Obviously, the answer for most of these right now is that you're not
supposed to do that. But as the smgrextend() + hash index case shows,
these things tend to grow in unexpected directions.

Also, slightly unrelated to the API, did we consider COW file systems?
Like, is explicitly allocating blocks of zeroes sensible on btrfs?