Обсуждение: NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...

Considered unexpected behavior, or at least in its undocumented form.  
If value given to NOTIFY seems schema-qualified, the schema  
qualification is eroded by the time it is presented to the listener --  
the [ nonexistent ] schema-ish-looking 'foo.' portion of 'foo.bar' is  
not presented at all to the listening end -- just 'bar'

-----

$ psql
Welcome to psql 8.2.11, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms       \h for help with SQL commands       \? for help with psql commands
\gor terminate with semicolon to execute query       \q to quit
 

social=# listen foo.bar;
LISTEN
social=# notify foo.bar;
NOTIFY
Asynchronous notification "bar" received from server process with PID  
5663.
social=# \q

-------

I expect this behavior is for the benefit of notify / listen users who  
happen to pass table name values over and / or when postgres became  
schema aware -- are listen condition names implicitly separated by  
schemas [ but if so, why would a listen for a schema-qualified name  
'foo.bar' succeed when schema 'foo' does not exist? Create table  
certainly wouldn't. ]

The docs for listen / notify don't mention any sort of parsing / value  
filtering of the notification signal value if it smelt schema  
qualified, just that a common use is for it to hold a table name. I  
wandered into this surprise by holding a dotted constant shared  
between my notifier and my listener [ who listens for a few different  
types of events, separated by notification names ], but the listener  
didn't receive the expected string with schema qualification, it got  
the eroded value instead -- easily worked around by not using  
constants containing dotted strings, but this was found to be  
surprising.

Aah -- gram.y shows LISTEN / NOTIFY taking a qualified_name production  
as their argument, and it seems to split up a dotted name into  
schema / relname subcomponents.

Probably least effort to have the docs mention listen / notify values  
containing periods are eroded to their relname portion, and that > 2  
dots == death:

social=# listen foo.bar.blat.blam;
ERROR:  improper qualified name (too many dotted names):  
foo.bar.blat.blam


Thanks!

----
James Robinson
Socialserve.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> Considered unexpected behavior, or at least in its undocumented form.
> If value given to NOTIFY seems schema-qualified, the schema
> qualification is eroded by the time it is presented to the listener --

See:

http://archives.postgresql.org//pgsql-patches/2007-02/msg00437.php

Pretty sure 8.4 will not use "relation".

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200904152332
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAknmpxMACgkQvJuQZxSWSsgifwCggRQSGppTLQ8zYCVsUUjI3ItR
s0kAnRnpWhmU4AYdQzmEaM5pfEhsfv4z
=FJc+
-----END PGP SIGNATURE-----