On Tue, Jun 29, 2021 at 03:34:29PM -0400, Tom Lane wrote: > Actually, I'd forgotten that the PQExpBuffer functions are already > exported by libpq, and much of our frontend code already uses them > from there. So we don't really need to move anything unless there's > a call to use this code in clients that don't use libpq, which are > a pretty small set. > > Also, having them be available both from libpq.so and from libpgcommon.a > would be a tad problematic I think; it'd be hard to tell which way the > linker would choose to resolve that.
Coming back to this thread. You were thinking about switching to PQExpBuffer for the error strings generated depending on error code for the frontend, right? Using a PQExpBuffer would be a problem if attempting to get a more detailed error for pg_verifybackup, though I guess that we can continue to live in this tool without this much amount of details in the error strings. It seems to me that this does not address yet the problems with the palloc/pstrdup in jsonapi.c though, which would need to rely on malloc() if we finish to use this code in libpq. I am not sure yet that we have any need to do that yet as we may finish by not using OAUTH as SASL mechanism at the end in core. So perhaps it would be better to just give up on this thread for now? -- Michael
signature.asc
Description: PGP signature
