Michael Paquier <michael@xxxxxxxxxxx> writes: > On Thu, Jan 06, 2022 at 11:40:04AM -0500, Tom Lane wrote: >> Also, I wonder if this shouldn't be unified with the SSLerrmessage() >> support found in be-secure-openssl.c and fe-secure-openssl.c. > Guess so. HEAD could be poked at for this part. I recall looking at > that once by that did not seem worth the complications. Yeah, I suppose there's only a couple lines of code to be saved, and the complexity of dealing with multiple memory allocation conventions would outweigh that. > What do you think? Hm, you still have cast-away-const in md5_crypt_verify and plain_crypt_verify. Can we adjust their APIs to make them return const char * as well (and then their API spec is that the caller must never free the string, rather than being vague about it)? The other thing that bothers me slightly is that it looks like some code paths could end up passing a NULL string pointer to ereport or sprintf, since you don't positively guarantee that an error will return a string there. I suppose this is safe since 3779ac62d, but I don't really want to start making API specs depend on it. regards, tom lane
