On Fri, 30 Aug 2024 at 13:04, Andy Fan <zhihuifan1...@163.com> wrote: > > David Rowley <dgrowle...@gmail.com> writes: > > If there's anywhere we call output functions > > where the resulting value isn't directly appended to a StringInfo, > > then we could just use a temporary StringInfo to obtain the cstring > > and its length. > > I think this is true, but it requests some caller's code change.
Yeah, calling code would need to be changed to take advantage of the new API, however, the differences in which types support which API could be hidden inside OutputFunctionCall(). That function could just fake up a StringInfo for any types that only support the old cstring API. That means we don't need to add handling for both cases everywhere we need to call the output function. It's possible that could make some operations slightly slower when only the old API is available, but then maybe not as we do now have read-only StringInfos. Maybe the StringInfoData.data field could just be set to point to the given cstring using initReadOnlyStringInfo() rather than doing appendBinaryStringInfo() onto yet another buffer for the old API. David
