Yes, there is a wrapper itcl package called Pg_sql that puts a OO feel on
top of the raw library calls. I thought this abstraction was shipped with
libpgtcl, but it seems it was developed here by one of our developers (since
departed from the company :-). The abstraction is very straight forward:
class pg_sql::Pg_sql {constructor {args} {}destructor {}
public { method select {} method listend {notifyname callback} #etc..}private { variable db}
}
body pg_sql::Pg_sql::listen {notifyname callback} {return [pg_listen $db $notifyname $callback]
}
So I think the syntax is ok.
But I think I've identified my problem in any case. I've been trying to
limit the downtime of the functionality that this script provides by running
it from its new location while the live one is still running - connected to
the same db. So since the live one has already registered a callback on
these events, the test script don't get any notifications, I assume? The
docs don't explicitly say what will happen in these circumstances, but it
makes sense that only one callback is fired for each event.
Will have to wait until after hours to test this then.
Thanks for the input.
Judith
-----Original Message-----
From: Brett Schwarz [mailto:brett_schwarz@yahoo.com]
Sent: 31 January 2006 05:52
To: Judith Retief; 'pgsql-interfaces@postgresql.org'
Subject: Re: [INTERFACES] sql listen fails using libpgtcl
I haven't seen that syntax before. Are you sure you
don't want:
pg_listen dbHandle notifyName callbackCommand
http://www.postgresql.org/docs/7.3/interactive/pgtcl-pglisten.html
are you using some other package, either standalone,
or that wraps around libpgtcl? It almost sounds like
you are using some wrapper package that didn't get
moved to the other machine...
--brett
--brett
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
