Notify argument?

Notify argument?

Post by Neil Conw » Fri, 22 Mar 2002 13:56:16





> > 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

--

PGP Key ID: DB3C29FC

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

 
 
 

Notify argument?

Post by Bruce Momji » Fri, 22 Mar 2002 14:15:23





> > > 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

  +  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

message can get through to the mailing list cleanly

 
 
 

Notify argument?

Post by Tom La » Fri, 22 Mar 2002 14:17:09



>> 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.

I hear you ... but my proposal only requires a recompile, *not* any
source code changes.  Renaming the field would break client source code.
I doubt it's worth that.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

 
 
 

Notify argument?

Post by Neil Conw » Fri, 22 Mar 2002 14:21:38




> >> 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.

> I hear you ... but my proposal only requires a recompile, *not* any
> source code changes.  Renaming the field would break client source code.
> I doubt it's worth that.

Okay, that's fair -- I'll leave it as it is.

Cheers,

Neil

--

PGP Key ID: DB3C29FC

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

 
 
 

1. listen/notify argument (old topic revisited)

A while ago, I started a small discussion about passing arguments to a NOTIFY
so that the listening backend could get more information about the event.

There wasn't exactly a consensus from what I understand, but the last thing I
remember is that someone intended to speed up the notification process by
storing the events in shared memory segments (IIRC this was Tom's idea). That
would create a remote possibility of a spurious notification, but the idea is
that the listening application can check the status and determine what
happened.

I looked at the TODO, but I couldn't find anything, nor could I find anything
in the docs.

Is someone still interested in implementing this feature? Are there still
people who disagree with the above implementation strategy?

Regards,
        Jeff

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

2. Replication accross the Net

3. Notify argument?

4. Copying paradox database tables into new tables

5. listen/notify argument (old topic revisited)

6. Choices for ODBC on PC

7. Notify argument?

8. Visual Basic Book Reviews

9. SP with unknown number of arguments or one delimited argument

10. DBD::Pg and NOTIFY (was Re: [GENERAL] Synchronous LISTEN/NOTIFY?)

11. Notifying NT User account by email

12. Notifying more than one operator

13. Notify on insert