>>It definitely affects how
>> backslashes are interpreted, and unless the current version of the
>>JDBC driver injects the 'E' escape syntax (with the 'E' prefix,
>>backslash escape sequences are interpreted regardless of the setting)
>>in a cavalier manner into the LIKE expression comparisons for
>> getColumns() (the one I have handy doesn't seem to), you should see
>>different behavior.
>Regardless of the setting of standard_conforming_strings passing \_ to
getColumns() always works properly.
Standard conforming strings makes sequences such as '\n' be treated as
literals unless you prefix an "E". When you use LIKE the '_' and '%' take
on special properties (which they do not have in a regular string) -
regardless of standard conforming strings since the use of LIKE means you
intend to make use of those special characters. In order to avoid the
special meaning of those two characters LIKE defines an escape character.
Since PostgreSQL controls both, you request the escape from PostgreSQL and
it provides what you need to perform the escape properly based upon the
current system configuration.
I hope this helps and that I'm not getting anything really wrong...
