Fix LIKE underscore escaping in PostgreSQL schema filtering

[amillet]

Use an explicit ESCAPE '$' clause in all LIKE patterns that filter out PostgreSQL system schemas (pg_*).

The previous patterns relied on the backslash as the default LIKE escape character. This works correctly when standard_conforming_strings is ON (the default since PostgreSQL 9.1), but fails when the setting is OFF: the backslash in the string literal 'pg_%' is consumed by the string parser before reaching the LIKE operator, turning the underscore into a wildcard instead of a literal match.

Using a non-backslash ESCAPE character makes the behavior explicit and correct regardless of the standard_conforming_strings setting.

[derrabus]

The previous patterns relied on the backslash as the default LIKE escape character. This works correctly when standard_conforming_strings is ON (the default since PostgreSQL 9.1), but fails when the setting is OFF

Is there a reason why anyone would operate their server with this setting disabled? I'm asking because we're not testing DBAL with this configuration, so there's a chance that more stuff is broken or will be broken in the future.

Is it possible to toggle this setting per session? In that case, I'd rather document that we require standard_conforming_strings to be set to on and maybe offer a middleware that does that.

[owengo]

@derrabus the reason is that the default was the opposite before 9.1 and the change requires a wide applicative update , so applications which were using postgres before postgres 9.1 may not have migrated to the new default ( why would they ? they just have to keep the value 'off' , much cheaper than rewrite code ).
Altering dynamically the session is potentially destructive as all requests using the session after the SET will be affected and will potentially break because of the change. Also doing SET breaks the usage of transaction pooling with pgbouncer as it will pollute randomly pooled sessions reused afterwards.