Paul Lambert <paul.lambert@autoledgers.com.au> writes:
> for example, the psqlodbc_<pid>.log file has the following when I
> attempt to link a table called billing_code:
> select n.nspname, c.relname, a.attname, a.atttypid, t.typname, a.attnum,
> a.attlen, a.atttypmod, a.attnotnull, c.relhasrules, c.relkind, c.oid,
> d.adsrc from (((pg_catalog.pg_class c inner join pg_catalog.pg_namespace
> n on n.oid = c.relnamespace and c.relname like 'billing\\_code' and
> n.nspname like 'public') inner join pg_catalog.pg_attribute a on (not
> a.attisdropped) and a.attnum > 0 and a.attrelid = c.oid) inner join
> pg_catalog.pg_type t on t.oid = a.atttypid) left outer join pg_attrdef d
> on a.atthasdef and d.adrelid = a.attrelid and d.adnum = a.attnum order
> by n.nspname, c.relname, attnum'
> Note the 'billing\\_code' in there.
> If I run this query in psql I get no rows. If I change it to
> 'billing\_code' or 'billing_code' (taking out one or both of the
> backslashes) I get the table details.
It sounds like you have standard_conforming_strings turned ON (making
backslashes not special in string literals) but there is some part of
the client-side code that is not aware of that, and thinks it needs to
double the backslash in the LIKE pattern. Either turn off
standard_conforming_strings or make sure you are using code that is
new enough to cope.
regards, tom lane