Neil Conway wrote: > On Wed, Mar 20, 2002 at 04:10:14PM -0500, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> 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?
Renaming the column would make an API change. I was talking only about requiring a recompile. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
