From: Andy Fan <zhihuifan1213@163.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,  pgsql-hackers@postgresql.org
Subject: Re: GetRelationPath() vs critical sections
In-Reply-To: 
 <CA+hUKGLAznzOPc34+qYAumJz+P66sc58XkM+68NO=xstoVwQ6A@mail.gmail.com>
	(Thomas Munro's message of "Thu, 5 Sep 2024 08:46:57 +1200")
References: <h3a7ftrxypgxbw6ukcrrkspjon5dlninedwb5udkrase3rgqvn@3cokde6btlrl>
	<CA+hUKGLAznzOPc34+qYAumJz+P66sc58XkM+68NO=xstoVwQ6A@mail.gmail.com>
Date: Sun, 06 Oct 2024 11:53:59 +0800
Message-ID: <874j5plwdk.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/874j5plwdk.fsf%40163.com>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:

> On Thu, Sep 5, 2024 at 3:58=E2=80=AFAM Andres Freund <andres@anarazel.de>=
 wrote:
>> Obviously we could add a version of GetRelationPath() that just prints i=
nto 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%3DUpG=
vY1tTF%3D4QU_0U_07EFaKmH7Nr%2BNLQ%40mail.gmail.com#aa061db119ee7a4b5390af56=
e24f475d

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

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=20
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=20=20
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).

--=20
Best Regards
Andy Fan