Re: signals in ODBC?
От | Thomas Lockhart |
---|---|
Тема | Re: signals in ODBC? |
Дата | |
Msg-id | 39F6F11D.79C5800B@alumni.caltech.edu обсуждение исходный текст |
Ответ на | signals in ODBC? (Kovacs Zoltan Sandor <tip@pc10.radnoti-szeged.sulinet.hu>) |
Ответы |
Re: signals in ODBC?
Re: signals in ODBC? |
Список | pgsql-interfaces |
> 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
В списке pgsql-interfaces по дате отправления: