listen not schema-aware

Started by Agent Malmost 20 years ago3 messages
#1Agent M
agentm@themactionfaction.com

Why is the schema ignored entirely when using listen/notify? I couldn't
find any mention of this in the documentation.

Ideally, it should support schemas (and store any string it takes) but
it should at least throw an error when a schema is prepended. I guess
the workaround is to simply delete the period.

client 1:
listen schema1.msg;

client 2:
notify schema1.msg;
notify schema2.msg;

client 1:
Asynchronous notification "msg" received from server process with PID X.
Asynchronous notification "msg" received from server process with PID X.

¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬

#2Neil Conway
neilc@samurai.com
In reply to: Agent M (#1)
Re: listen not schema-aware

On Fri, 2006-03-31 at 20:27 -0500, Agent M wrote:

Why is the schema ignored entirely when using listen/notify?

Per the docs:

Commonly, the notification name is the same as the name of some
table in the database, and the notify event essentially means, "I
changed this table, take a look at it to see what's new". But no
such association is enforced by the NOTIFY and LISTEN commands.

i.e. the LISTEN/NOTIFY argument is not the name of a relation, so it
wouldn't make much sense to schema-qualify it.

-Neil

#3Tom Lane
tgl@sss.pgh.pa.us
In reply to: Neil Conway (#2)
Re: listen not schema-aware

Neil Conway <neilc@samurai.com> writes:

i.e. the LISTEN/NOTIFY argument is not the name of a relation, so it
wouldn't make much sense to schema-qualify it.

I'm not entirely sure why we even have the grammar allowing qualified
names in these statements. It's not documented that you can do that.

regards, tom lane