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

Started by James Robinsonover 16 years ago3 messages
#1James Robinson
jlrobins@socialserve.com

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

#2Greg Sabino Mullane
greg@turnstep.com
In reply to: James Robinson (#1)
Re: NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...

-----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-----

#3James Robinson
jlrobins@socialserve.com
In reply to: Greg Sabino Mullane (#2)
Re: NOTIFY / LISTEN silently parses and discards schema-ish portion of notification name ...

On Apr 16, 2009, at 6:51 AM, pgsql-hackers-owner@postgresql.org wrote:

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".

Thanks for pointer on a proposed patch, Greg. That patch looks like it
hasn't been applied to the 8.2 maintenance stream.

Looks like in 8.3 the grammar changed the name argument to ColId
production, which goes unparsed. Shame on me for using such an old
version [ 8.2 ], but hey, it works.

----
James Robinson
Socialserve.com