NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...

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

Responses

Browse pgsql-hackers by date

  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