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

Поиск
Список
Период
Сортировка
От James Robinson
Тема NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...
Дата
Msg-id 55658BAF-ADE8-467C-ADF8-918AF10DA1DB@socialserve.com
обсуждение исходный текст
Ответы Re: NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...  ("Greg Sabino Mullane" <greg@turnstep.com>)
Список 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
\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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: HashJoin w/option to unique-ify inner rel
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: psql with "Function Type" in \df