OK, patch applied to document PQfreemem() for notify.
PQfreeNotify wasn't even documented, but I kept it in for binary
compatibility, and added a #define to map it to PQfreemem().
I updated various interfaces to use PQfreemem() rather than free().
---
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > The problem with that is the new versions are still going to reference
> > PQfreeNotify, and then we still can't remove it. I think we need the
> > macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
> > function around for
Bruce Momjian writes:
> The problem with that is the new versions are still going to reference
> PQfreeNotify, and then we still can't remove it. I think we need the
> macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
> function around for a release or two, then remove it, an
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > The problem with that is the new versions are still going to reference
> > PQfreeNotify, and then we still can't remove it. I think we need the
> > macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
> > function ar
Bruce Momjian <[EMAIL PROTECTED]> writes:
> The problem with that is the new versions are still going to reference
> PQfreeNotify, and then we still can't remove it. I think we need the
> macro for PQfreeNotify pointing to PQfreemem, but keep the PQfreeNotify
> function around for a release or two,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Do we really want "PQfreemem" either? Maybe it should be "PQfree"?
>
> > I am a little concerned that PQfree would be confused with PQclear.
>
> Good point --- nevermind that suggestion.
>
> > Could we have PQfreeNotify() be a mac
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Do we really want "PQfreemem" either? Maybe it should be "PQfree"?
> I am a little concerned that PQfree would be confused with PQclear.
Good point --- nevermind that suggestion.
> Could we have PQfreeNotify() be a macro to PQfreemem in 7.4?
I'd lik
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Doesn't this duplicate a function that we already invented for PQnotify
> > >> structs?
> >
> > > What do you recommend? Do we depricate PQfreeNotify?
> >
> > I dunno. In hindsight
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Doesn't this duplicate a function that we already invented for PQnotify
> >> structs?
>
> > What do you recommend? Do we depricate PQfreeNotify?
>
> I dunno. In hindsight it was shortsightedly named. But I don
I have modified the patch to call it PQfreemem(), in case there are other
cases we need to free libpq memory.
Patch attached and applied.
---
Zeugswetter Andreas SB SD wrote:
>
> > Actually this isn't even working for me.
e addition of:
PQescapeByteaFree(unsigned char *);
-Dave
From: Joe Conway <[EMAIL PROTECTED]>
To: Key88 SF <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [HACKERS] PQescapeBytea on Win32
Date: Mon, 17 Mar 2003 21:41:26 -0800
MIME-Version: 1.0
Received:
Yes, I am aware of that limitation. If you link libpq as a
Multithreaded DLL, it will not link libc into each DLL, but have only
one libc that can free from anywhere.
Is that acceptable or do we need a Win32 specific memory free function?
---
Hi - there is a problem with PQescapeBytea for Win32. Since libpq is a DLL,
all memory allocated from within the DLL needs to be freed from within the
dll.
PQescapeBytea allocates memory, but there is no function call back into the
DLL to free this memory. This causes heap corruption when the m
13 matches
Mail list logo
