Re: [GENERAL] Notify argument?
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] Notify argument? |
Дата | |
Msg-id | 7310.1016658614@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [GENERAL] Notify argument?
Re: [GENERAL] Notify argument? Re: [GENERAL] Notify argument? |
Список | 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 по дате отправления: