pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedsql listen fails using libpgtcl
5+ messages / 3 participants
[nested] [flat]
* sql listen fails using libpgtcl
@ 2006-01-31 09:42 Judith Retief <JudithR@inet.co.za>
0 siblings, 1 reply; 5+ messages in thread
From: Judith Retief @ 2006-01-31 09:42 UTC (permalink / raw)
To: pgsql-interfaces
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.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: sql listen fails using libpgtcl
@ 2006-01-31 15:52 Brett Schwarz <brett_schwarz@yahoo.com>
parent: Judith Retief <JudithR@inet.co.za>
0 siblings, 0 replies; 5+ messages in thread
From: Brett Schwarz @ 2006-01-31 15:52 UTC (permalink / raw)
To: Judith Retief <JudithR@inet.co.za>; pgsql-interfaces
--- 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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: sql listen fails using libpgtcl
@ 2006-02-01 05:37 Judith Retief <JudithR@inet.co.za>
0 siblings, 1 reply; 5+ messages in thread
From: Judith Retief @ 2006-02-01 05:37 UTC (permalink / raw)
To: Brett Schwarz <brett_schwarz@yahoo.com>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: sql listen fails using libpgtcl
@ 2006-02-01 14:26 Tom Lane <tgl@sss.pgh.pa.us>
parent: Judith Retief <JudithR@inet.co.za>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2006-02-01 14:26 UTC (permalink / raw)
To: Judith Retief <JudithR@inet.co.za>; +Cc: 'Brett Schwarz' <brett_schwarz@yahoo.com>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: sql listen fails using libpgtcl
@ 2006-02-02 04:17 Judith Retief <JudithR@inet.co.za>
0 siblings, 0 replies; 5+ messages in thread
From: Judith Retief @ 2006-02-02 04:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Brett Schwarz <brett_schwarz@yahoo.com>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2006-02-02 04:17 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-01-31 09:42 sql listen fails using libpgtcl Judith Retief <JudithR@inet.co.za>
2006-01-31 15:52 ` Brett Schwarz <brett_schwarz@yahoo.com>
2006-02-01 05:37 Re: sql listen fails using libpgtcl Judith Retief <JudithR@inet.co.za>
2006-02-01 14:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2006-02-02 04:17 Re: sql listen fails using libpgtcl Judith Retief <JudithR@inet.co.za>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox