Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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 like to do that but I doubt we can get away with it; it'd be
> an incompatible change at the binary API level, forcing a major
> version bump on libpq.so. (On the other hand, we might wind up
> doing one anyway; not sure.)
Right. We changed the Notify internal structure and got bitten on that
in 7.3 -- don't want that to happen again.
> You could do it the other way: PQfreemem a macro for PQfreeNotify.
> That would stay binary-compatible with existing clients. We could
> switch which one is a macro at the next occasion for a major
> version bump on the shlib, and then eventually remove PQfreeNotify
> when we feel it's been deprecated for long enough.
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, and remove all
documentation about it in 7.4.
I now see that psql doesn't use that call, though it should if it is
running on Win32:static voidPrintNotifications(void){ PGnotify *notify; while ((notify = PQnotifies(pset.db)))
{ fprintf(pset.queryFout, gettext("Asynchronous NOTIFY '%s' from backend with pid %d received.\n"),
notify->relname, notify->be_pid); free(notify); fflush(pset.queryFout); }}
I will clean that up too, and check any other interfaces/apps.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073