Re: [GENERAL] Notify argument?

Neil Conway wrote:
> On Wed, Mar 20, 2002 at 04:10:14PM -0500, Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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?

Renaming the column would make an API change. I was talking only about
requiring a recompile.

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