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?
---
12 matches
Mail list logo
