From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Euler Taveira <euler(at)eulerto(dot)com>, "ranier(dot)vf(at)gmail(dot)com" <ranier(dot)vf(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Small memory fixes for pg_createsubcriber |
Date: | 2025-02-12 23:56:53 |
Message-ID: | Z601RQxTmIUohdkV@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Feb 12, 2025 at 12:00:03PM -0500, Andres Freund wrote:
> Particularly for something like libpq it's not quitetrivial to add
> attributes like this, of course. We can't even depend on pg_config.h.
>
> One way would be to define them in libpq-fe.h, guarded by an #ifdef, that's
> "armed" by a commandline -D flag, if the compiler is supported?
Interesting set of tricks.
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.
The pg_upgrade path is fancy as designed this way, for sure, but
that's less invasive than hardcoding three times "NULL". Any thoughts
about backpatching something like that for both of them?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
libpq-escape-fixes.patch | text/x-diff | 847 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-02-12 23:59:58 | Re: Small memory fixes for pg_createsubcriber |
Previous Message | Sami Imseih | 2025-02-12 23:44:20 | Proposal - Allow extensions to set a Plan Identifier |