> On Tue, Jun 12, 2018 at 1:09 PM, Tsunakawa, Takayuki > <tsunakawa.ta...@jp.fujitsu.com> wrote: > > My colleague is now preparing a patch for that, which adds a function > ECPGFreeSQLDA() in libecpg.so. That thread is here: > > > https://www.postgresql.org/message-id/25C1C6B2E7BE044889E4FE8643A58BA9 > 63A42097@G01JPEXMBKW03 > > Thanks. I will follow up on that thread.
He's created a separate thread for a new CF entry here: https://commitfest.postgresql.org/18/1669/ > > I want some remedy for older releases. Our customer worked around this > problem by getting a libpq connection in their ECPG application and calling > PQfreemem(). That's an ugly kludge, and I don't want other users to follow > it. > > > > I don't see a problem with back-patching as-is, because existing users > who just call free() or don't call free() won't be affected. I think that > most serious applications somehow state their supported minor releases like > "this application supports (or is certified against) PostgreSQL 10.5 or > later", just like other applications support "RHEL 6.2 or later" or "Windows > XP Sp2 or later." > > If there is a consensus that we should do that then I'll back-patch, > but so far no one else has spoken up in support. I'll follow the community decision. But I'm afraid that not enough people will comment on this to call it a consensus, because this topic will not be interesting... FWIW, I thought back-patching would make committers' future burdon smaller thanks to the smaller difference in the code of multiple major versions. Regards Takayuki Tsunakawa
