Thomas Munro <thomas.mu...@gmail.com> writes: > On Thu, Sep 5, 2024 at 3:58 AM Andres Freund <and...@anarazel.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
