Re: GetRelationPath() vs critical sections

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:

> On Thu, Sep 5, 2024 at 3:58 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> Obviously we could add a version of GetRelationPath() that just prints into a
>> caller provided buffer - but that's somewhat awkward API wise.
>
> For the record, that's exactly what I did in the patch I proposed to
> fix our long standing RelationTruncate() data-eating bug:
>
> https://www.postgresql.org/message-id/flat/CA%2BhUKG%2B5nfWcpnZ%3DZ%3DUpGvY1tTF%3D4QU_0U_07EFaKmH7Nr%2BNLQ%40mail.gmail.com#aa061db119ee7a4b5390af56e24f475d

I want to have a dicussion on the user provided buffer APIs. I just get
the similar feedback on [1] because of this recently..

I agree that "user provided buffer" API is bad for the reasons like:
a). inconvenient since user need to provide the buffer. b) unsafe
because user may provide a incorrect buffer. But it still have some
advantages, like c). allocate the memory in a expected MemoryContext
rather than CurrentMemoryContext. d). Allocating the memory at the
different time rather than executing the API e). API can write the data
to the user descired buffer directly rather than another
copy after. My user case at [1] is because of (c) and (e), and the user
case here looks because of factor (d).

Come to the badness of "user provided buffer" API, I think we can ease
them by providing both the non-user-buffer API and user-provided-buffer
API. Since the later one is safe and convenient, so
people probably user the non-user-buffer API by default and just the
user who wants the benefits of "provided-buffer" would use that API.

Am I miss some important factors on this topic?

[1]
https://www.postgresql.org/message-id/1882669.1726701697%40sss.pgh.pa.us

(I read the above topic [1] now, I just realize I proposed to [change] the
API rather than adding an new variant, that's not my intention and
that's my fault).

--
Best Regards
Andy Fan