Michael Paquier <mich...@paquier.xyz> writes:
> I have looked at bit at the uses of PQescapeLiteral() and
> PQescapeIdentifier() in the tree. On top of the one in pg_amcheck you
> are just pointing to, there is an inconsistency in pg_upgrade.c for
> set_locale_and_encoding() where datlocale_literal may be allocated
> with a pg_strdup() or a PQescapeLiteral() depending on the path. The
> code has been using PQfreemem() for the pg_strdup() allocation, which
> is logically incorrect.
Yeah, I suspected there would be places like that. It just hasn't
mattered in practice up to now. (I have a vague recollection that
Windows used to be pickier about this, but evidently not in recent
years.)
I spent a little time earlier today seeing what I could do with the
use-dmalloc patch I posted earlier. It turns out you can get through
initdb after s/free/PQfreemem/ in just two places, and then the
backend works fine. But psql is a frickin' disaster --- there's
free's of strings made with PQExpBuffer all over its backslash-command
handling, and no easy way to clean it up. Maybe other clients will
be less of a mess, but I'm not betting on that.
regards, tom lane
