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

From Bruce Momjian
Subject Re: [GENERAL] Notify argument?
Date
Msg-id 200204152336.g3FNa4u05906@candle.pha.pa.us
Whole thread Raw
In response to Re: [GENERAL] Notify argument?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Fix applied.

---------------------------------------------------------------------------

Tom Lane wrote:
> 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
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [PATCHES] [patch] fe-connect.c doesn't handle EINTR correctly
Next
From: Hiroshi Inoue
Date:
Subject: Re: Operators and schemas