Re: [GENERAL] Notify argument?
От | nconway@klamath.dyndns.org (Neil Conway) |
---|---|
Тема | Re: [GENERAL] Notify argument? |
Дата | |
Msg-id | 20020321045542.GA12420@klamath.dyndns.org обсуждение исходный текст |
Ответ на | Re: [GENERAL] Notify argument? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [GENERAL] Notify argument?
Re: [GENERAL] Notify argument? |
Список | pgsql-hackers |
On Wed, Mar 20, 2002 at 04:10:14PM -0500, 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. Sounds good. If we're making other backwards-incompatible changes to pgNotify, one thing that bugs me about the API is the use of "relname" to refer to name of the NOTIFY/LISTEN condition. This is incorrect because the name of a condition is _not_ the name of a relation -- there is no necessary correspondence between these. The names of NOTIFY conditions are arbitrary, and chosen by the application developer. The same terminology is used in the backend NOTIFY/LISTEN code (e.g. pg_listener), but the major source of incompatibility will be the change to libpq. Would it be a good idea to rename "relname" to something more sensible? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
В списке pgsql-hackers по дате отправления: