Message-ID: <39F6F11D.79C5800B@alumni.caltech.edu>
Date: Wed, 25 Oct 2000 14:41:33 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
Organization: Yes
MIME-Version: 1.0
To: Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: signals in ODBC?
References: 
 <Pine.LNX.4.05.10010251411460.30412-100000@pc10.radnoti-szeged.sulinet.hu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> My goal is for a connection to receive signals from other connections.
> E.g., I would get the information about changing a row of a table by
> an other connection. This would be great having the information at once.
> An ugly and slow solution is to send queries to the server e.g. twice
> a minute or so---but is there a better way?

afaik we need multithreaded clients (and servers) to be able to do this.
It would be a nice capability, but asynchronous communication requires
that you set up a separate thread to receive a callback. I'm pretty sure
we have none of the required infrastructure in our existing
communication protocol.

> Browsing the documentation I found NOTIFY and LISTEN. Can I use them
> within an ODBC connection? Is it possible to catch a NOTIFY signal this way?

LISTEN happens on a table (or actually any arbitrary name; it doesn't
need an underlying object). But afaik you have to do a query to get your
LISTEN to fire on the client, since none of our clients are
multithreaded.

> As I realized, the NOTIFY statement doesn't have a second parameter,
> i.e. I cannot give any other signal to an other connection than
> "Yes" or "No". What about future plans?

No future plans afaik. Commercial Ingres allowed a text string to be
associated with a NOTIFY message, which presumably would require a more
involved (and difficult to manage) underlying structure to be created.

                       - Thomas