head	1.5;
access;
symbols
	REL7_2_8:1.4
	REL7_2_7:1.4
	REL7_2_6:1.4
	REL7_2_5:1.4
	REL7_2_4:1.4
	REL7_2_3:1.4
	REL7_2_STABLE:1.4.0.6
	REL7_2:1.4
	REL7_2_RC2:1.4
	REL7_2_RC1:1.4
	REL7_2_BETA5:1.4
	REL7_2_BETA4:1.4
	REL7_2_BETA3:1.4
	REL7_2_BETA2:1.4
	REL7_2_BETA1:1.4
	REL7_1_2:1.4
	REL7_1_STABLE:1.4.0.4
	REL7_1_BETA:1.4
	REL7_1_BETA3:1.4
	REL7_1_BETA2:1.4
	REL7_1:1.4
	REL7_0_PATCHES:1.4.0.2
	REL7_0:1.4
	REL6_5_PATCHES:1.1.0.2;
locks; strict;
comment	@# @;


1.5
date	2002.08.30.16.48.43;	author momjian;	state dead;
branches;
next	1.4;

1.4
date	99.10.30.16.18.51;	author momjian;	state Exp;
branches;
next	1.3;

1.3
date	99.10.30.16.01.14;	author momjian;	state dead;
branches;
next	1.2;

1.2
date	99.09.20.22.30.47;	author scrappy;	state Exp;
branches;
next	1.1;

1.1
date	99.09.13.18.47.31;	author momjian;	state dead;
branches
	1.1.2.1;
next	;

1.1.2.1
date	99.09.13.18.47.31;	author momjian;	state Exp;
branches;
next	;


desc
@@


1.5
log
@Remove pgaccess from CVS.  It has its own home now.
@
text
@.pgaw:Help.f.t insert end "LISTEN" {bold} " registers the current Postgres backend as a listener on the notify condition notifyname.  \

Whenever the command NOTIFY notifyname is invoked, either by this backend or another one connected to the same database, all the backends currently listening on that notify condition are \
notified, and each will in turn notify its connected frontend application. See the discussion of NOTIFY for more information.  \

A backend can be deregistered for a given notify condition with the UNLISTEN command. Also, a backend's listen registrations are automatically cleared when the backend process exits.  \

The method a frontend application must use to detect notify events depends on which Postgres application programming interface it uses. With the basic libpq library, the application issues \
LISTEN as an ordinary SQL command, and then must periodically call the routine PQnotifies to find out whether any notify events have been received. Other interfaces such as libpgtcl provide \
higher-level methods for handling notify events; indeed, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. See the documentation for the library \
you are using for more details. 

The reference page for NOTIFY contains a more extensive discussion of the use of LISTEN and NOTIFY. 

" {} "Synopsis" {bold} "

LISTEN notifyname

" {} "Usage" {bold} "
" {} "
                -- Configure and execute a listen/notify sequence from psql
                postgres=> listen virtual;
                LISTEN
                postgres=> notify virtual;
                NOTIFY
                ASYNC NOTIFY of 'virtual' from backend pid '11239' received
                
" {code} "Notes" {bold} "

notifyname can be any string valid as a name; it need not correspond to the name of any actual table. If notifyname is enclosed in double-quotes, it need not even be a syntactically valid name, \
but can be any string up to 31 characters long. 

In some previous releases of Postgres, notifyname had to be enclosed in double-quotes when it did not correspond to any existing table name, even if syntactically valid as a name. That is no \
longer required. "
@


1.4
log
@Add 0.98.
@
text
@@


1.3
log
@Remove 0.96 for update to 0.98
@
text
@@


1.2
log
@
bring it all into -current again
@
text
@@


1.1
log
@file listen.hlp was initially added on branch REL6_5_PATCHES.
@
text
@d1 34
@


1.1.2.1
log
@Update pgaccess 0.98
@
text
@a0 34
.pgaw:Help.f.t insert end "LISTEN" {bold} " registers the current Postgres backend as a listener on the notify condition notifyname.  \

Whenever the command NOTIFY notifyname is invoked, either by this backend or another one connected to the same database, all the backends currently listening on that notify condition are \
notified, and each will in turn notify its connected frontend application. See the discussion of NOTIFY for more information.  \

A backend can be deregistered for a given notify condition with the UNLISTEN command. Also, a backend's listen registrations are automatically cleared when the backend process exits.  \

The method a frontend application must use to detect notify events depends on which Postgres application programming interface it uses. With the basic libpq library, the application issues \
LISTEN as an ordinary SQL command, and then must periodically call the routine PQnotifies to find out whether any notify events have been received. Other interfaces such as libpgtcl provide \
higher-level methods for handling notify events; indeed, with libpgtcl the application programmer should not even issue LISTEN or UNLISTEN directly. See the documentation for the library \
you are using for more details. 

The reference page for NOTIFY contains a more extensive discussion of the use of LISTEN and NOTIFY. 

" {} "Synopsis" {bold} "

LISTEN notifyname

" {} "Usage" {bold} "
" {} "
                -- Configure and execute a listen/notify sequence from psql
                postgres=> listen virtual;
                LISTEN
                postgres=> notify virtual;
                NOTIFY
                ASYNC NOTIFY of 'virtual' from backend pid '11239' received
                
" {code} "Notes" {bold} "

notifyname can be any string valid as a name; it need not correspond to the name of any actual table. If notifyname is enclosed in double-quotes, it need not even be a syntactically valid name, \
but can be any string up to 31 characters long. 

In some previous releases of Postgres, notifyname had to be enclosed in double-quotes when it did not correspond to any existing table name, even if syntactically valid as a name. That is no \
longer required. "
@
