From: | James Robinson <jlrobins(at)socialserve(dot)com> |
---|---|
To: | Hackers Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ... |
Date: | 2009-04-16 02:54:24 |
Message-ID: | 55658BAF-ADE8-467C-ADF8-918AF10DA1DB@socialserve.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-04-16 03:32:52 | Re: psql with "Function Type" in \df |
Previous Message | Robert Haas | 2009-04-16 02:54:16 | Re: HashJoin w/option to unique-ify inner rel |