Fix LISTEN with special characters in channel names#119
Fix LISTEN with special characters in channel names#119tsloughter merged 2 commits intoerleans:mainfrom
Conversation
Provides reproducible example for issue erleans#118: A channel containing special characters generates invalid SQL due to the pgo not escaping such identifiers.
By escaping channel names on the way to the database, the `listen` function is now able to function with special characters in channel names, as well as being safe from SQL injection. The names are NOT quoted when stored in the in-memory listener map, so that the raw channel names match with the names reported by the database when the notification occurs. Closes erleans#118
|
should there not just be quotes? |
|
https://www.postgresql.org/docs/current/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS This section of the Postgres documentation describes the syntax for identifiers:
|
|
Aah, ok. I was then debating if it should be up to the user to do it, but this is safer and I don't think surprising to the user. |
|
I attempted to do it as the user as it was written, and it didn't work. The database sends the string unescaped back when the notify is triggered, so the library with its pre-escaped string stored in memory cannot match the notification up to the registered listening processes. |
|
Good point. Thanks! |
2 participants
By escaping channel names on the way to the database, the
listenfunction is now able to function with special characters in channel
names, as well as being safe from SQL injection.
The names are NOT quoted when stored in the in-memory listener map,
so that the raw channel names match with the names reported by the
database when the notification occurs.
Closes #118