> On Tue, Jun 12, 2018 at 1:09 PM, Tsunakawa, Takayuki
> <tsunakawa.takay@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,
becausethis topic will not be interesting... FWIW, I thought back-patching would make committers' future burdon
smallerthanks to the smaller difference in the code of multiple major versions.
Regards
Takayuki Tsunakawa