Обсуждение: (libpq) listen/notify messages are converted to lowercase and/or are case insensitive

L.S.

Either the docs or I are missing something....

While using libpq I noticed that listen/notify calls were being converted to
lowercase. A further look showed that the listen/notify calls seem to be
totally case insensitive:

free4testing=# select version();
                               version
---------------------------------------------------------------------
 PostgreSQL 7.4.3 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66

free4testing=# listen barcode_needed;
LISTEN
free4testing=# notify BARCODE_NEEDED;
NOTIFY
Asynchronous notification "barcode_needed" received from server process with
PID 32638.
free4testing=# unlisten BARCODE_NEEDED;
UNLISTEN
free4testing=#


Obviously, things work and they probably work as intended, but I wasn't able
to find anything on this behaviour in the docs. For a moment I thought that
the syntax rule 'unquoted letters are forced to lowercase' of SQL applied
here as well, but any double quotes used are simply interpreted as part of
the name.

Any further comments on this are appreciated.



--
Best,




Frank.

On Sun, 15 Aug 2004, Frank van Vugt wrote:

> L.S.
>
> Either the docs or I are missing something....
>
> While using libpq I noticed that listen/notify calls were being converted to
> lowercase. A further look showed that the listen/notify calls seem to be
> totally case insensitive:
>
> free4testing=# select version();
>                                version
> ---------------------------------------------------------------------
>  PostgreSQL 7.4.3 on i686-pc-linux-gnu, compiled by GCC egcs-2.91.66
>
> free4testing=# listen barcode_needed;
> LISTEN
> free4testing=# notify BARCODE_NEEDED;
> NOTIFY
> Asynchronous notification "barcode_needed" received from server process with
> PID 32638.
> free4testing=# unlisten BARCODE_NEEDED;
> UNLISTEN
> free4testing=#
>
>
> Obviously, things work and they probably work as intended, but I wasn't able
> to find anything on this behaviour in the docs. For a moment I thought that
> the syntax rule 'unquoted letters are forced to lowercase' of SQL applied
> here as well, but any double quotes used are simply interpreted as part of
> the name.

On my 7.4.2 machine, I can get:

sszabo=# listen foo;
LISTEN
sszabo=# notify "FOO";
NOTIFY
sszabo=# notify "foo";
NOTIFY
Asynchronous notification "foo" received from server process with PID
7042.
sszabo=# notify FOO;
NOTIFY
Asynchronous notification "foo" received from server process with PID
7042.

So, it looks to me that "FOO" is not being casefolded while FOO is, which
would be consistent with the identifier folding rules.

Frank van Vugt <ftm.van.vugt@foxi.nl> writes:
> Obviously, things work and they probably work as intended, but I wasn't able
> to find anything on this behaviour in the docs. For a moment I thought that
> the syntax rule 'unquoted letters are forced to lowercase' of SQL applied
> here as well, but any double quotes used are simply interpreted as part of
> the name.

You had the right idea: the arguments of listen and notify commands are
identifiers.  I don't know what convinced you otherwise.

regression=# listen "Z";
LISTEN
regression=# notify Z;
NOTIFY
regression=# notify "Z";
NOTIFY
Asynchronous notification "Z" received from server process with PID 28818.
regression=# listen z;
LISTEN
regression=# notify "Z";
NOTIFY
Asynchronous notification "Z" received from server process with PID 28818.
regression=# notify Z;
NOTIFY
Asynchronous notification "z" received from server process with PID 28818.
regression=#

            regards, tom lane

> You had the right idea: the arguments of listen and notify commands are
> identifiers.  I don't know what convinced you otherwise.

Ah, this was the one I missed and somehow it confused me:

f4t=# listen "z";
LISTEN
f4t=# notify Z;
NOTIFY
Asynchronous notification "z" received from server process with PID 1800.
f4t=# notify "Z";
NOTIFY


Oh, and of course, _now_ the mentioning of 'identifier' in the notify-docs get
noticed as well ;)

Thanks to the both of you !



--
Best,




Frank.