Thread: Notify argument?
I am curious, why does notify not support a string argument of some kind, to
pass to the other connections? It seems it would be a little more useful.
My application does not exactly require this feature, but it seems more
intuitive. After all, the current implementation requires a separate "LISTEN"
for each possible event.
Is this due to oracle compatibility issues? Is it too difficult for it's
usefulness?
Thanks,
Jeff
On Tue, 2002-03-19 at 08:22, Jeff Davis wrote: > I am curious, why does notify not support a string argument of some kind, to > pass to the other connections? It seems it would be a little more useful. You can pass data around using temp tables. > Is this due to oracle compatibility issues? Actually, I think that Oracle's implementation of this feature actually allows for a user-specified string argument. > Is it too difficult for it's usefulness? AFAICT it shouldn't be too difficult. However, there is a note in the TODO list referring to breaking backwards compatability with the "pgNotify API". Exactly how backwards compatible do we need to be? Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote:
>
> > I am curious, why does notify not support a string argument of some kind, to
> > pass to the other connections? It seems it would be a little more useful.
> Actually, I think that Oracle's implementation of this feature actually
> allows for a user-specified string argument.
Commercial Ingres allowed one to specify a string also. I'm guessing
that the feature was not implemented in PostgreSQL *not* because there
is some good database design reason to leave it out, but rather because
someone did not bother to put it in.
> AFAICT it shouldn't be too difficult. However, there is a note in the
> TODO list referring to breaking backwards compatability with the
> "pgNotify API". Exactly how backwards compatible do we need to be?
imho not much in this case (though of course we may find a way to be
very compatible when someone actually implements it). I had found the
equivalent feature very useful when building a large data handling
system a few years ago, and I'd think that it would be useful in
PostgreSQL also. Comments?
- Thomas
On Wed, 2002-03-20 at 10:24, Thomas Lockhart wrote: > > AFAICT it shouldn't be too difficult. However, there is a note in the > > TODO list referring to breaking backwards compatability with the > > "pgNotify API". Exactly how backwards compatible do we need to be? > > imho not much in this case (though of course we may find a way to be > very compatible when someone actually implements it). I had found the > equivalent feature very useful when building a large data handling > system a few years ago, and I'd think that it would be useful in > PostgreSQL also. Okay, I'll implement this. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote: > > Is it too difficult for it's usefulness? > > AFAICT it shouldn't be too difficult. However, there is a note in the > TODO list referring to breaking backwards compatability with the > "pgNotify API". Exactly how backwards compatible do we need to be? 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. -- 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, Pennsylvania 19026
Bruce Momjian wrote:
> Neil Conway wrote:
> > > Is it too difficult for it's usefulness?
> >
> > AFAICT it shouldn't be too difficult. However, there is a note in the
> > TODO list referring to breaking backwards compatability with the
> > "pgNotify API". Exactly how backwards compatible do we need to be?
>
> 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.
Hmmm,
seems I have to get a little more familiar with the FE/BE
stuff again. Have been pretty good at that years ago.
IIRC, the FE/BE protocol itself does not limit any length or
depends on definitions like that. So that should be an
arbitrary (read bogus) usage in libpq. The TODO entry
therefore should read
Fix Notify API's usage of NAMEDATALEN.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com