Re: [GENERAL] Notify argument? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Notify argument?
Date
Msg-id 7310.1016658614@sss.pgh.pa.us
Whole thread Raw
Responses Re: [GENERAL] Notify argument?  (nconway@klamath.dyndns.org (Neil Conway))
Re: [GENERAL] Notify argument?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [GENERAL] Notify argument?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The breakage will come when we lengthen NAMEDATALEN, which I plan to
> tackle for 7.3.  We will need to re-order the NOTIFY structure and put
> the NAMEDATALEN string at the end of the struct so differing namedatalen
> backend/clients will work.  If you want to break it, 7.3 would probably
> be the time to do it.  :-)  Users will need a recompile pre-7.3 to use
> notify for 7.3 and later anyway.

If we're going to change the structure anyway, let's fix it to be
independent of NAMEDATALEN.  Instead of
   char        relname[NAMEDATALEN];   int         be_pid;

let's do
   char       *relname;   int         be_pid;

This should require no source-level changes in calling C code, thanks
to C's equivalence between pointers and arrays.  We can preserve the
fact that freeing a PQnotifies result takes only one free() with a
little hacking to make the string be allocated in the same malloc call:
   newNotify = (PGnotify *) malloc(sizeof(PGnotify) + strlen(str) + 1);   newNotify->relname = (char *) newNotify +
sizeof(PGnotify);  strcpy(newNotify->relname, str);
 

Thus, with one line of extra ugliness inside the library, we solve the
problem permanently.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Igor Kovalenko
Date:
Subject: Re: Fw: Fw: bad performance on irix
Next
From: Fernando Nasser
Date:
Subject: Re: Domains and type coercion