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
\g or 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
