Thread: sql listen fails using libpgtcl
Hi there I don't know too much about either TCL or Postgres, so this might be a really silly thing. Anyways. We've got a TCL script interfacing against a (remote) PG server using libpgtcl. I've got to move that script to another machine, where I've installed libpgtcl doing "apt-get install libpgtcl". Everything works (can connect to the remove db and do a few select statements), but where the script attempts a "sql listen <tablename> <notification>" statement I get a run-time error:"bad option 'listen': should be one of sql cget -option sql commit [etc]" The Postgres server is 7.2.1 on debian linux. On the machine where the script is working, the libpgtcl's debian package gives its version as 7.2.1-2woody4; where it's not working the version is 7.2.1-2woody8, if that is of help at all. Any ideas on what this could be? Thanks.
--- Judith Retief <JudithR@inet.co.za> wrote: > Hi there > > I don't know too much about either TCL or > Postgres, so this might be a > really silly thing. Anyways. We've got a TCL script > interfacing against a > (remote) PG server using libpgtcl. I've got to move > that script to another > machine, where I've installed libpgtcl doing > "apt-get install libpgtcl". > > Everything works (can connect to the remove db and > do a few select > statements), but where the script attempts a "sql > listen <tablename> > <notification>" statement I get a run-time error: > "bad option 'listen': should be one of > sql cget -option > sql commit > [etc]" > > The Postgres server is 7.2.1 on debian linux. > 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
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
Judith Retief <JudithR@inet.co.za> writes:
> 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?
No, NOTIFY delivers an event to *each* active listener for the given
event name.
regards, tom lane
Ok, found the problem. Really silly. Old version of the OO wrapper was
installed on the box - it didn't have the listen implemented in the wrapper
class yet. Grrrr....
Thanks for the support.
Judith
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 01 February 2006 04:27
To: Judith Retief
Cc: 'Brett Schwarz'; 'pgsql-interfaces@postgresql.org'
Subject: Re: [INTERFACES] sql listen fails using libpgtcl
No, NOTIFY delivers an event to *each* active listener for the given
event name.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster