Re: Backslash and Underscore problem with DBI and PostgreSQL.

[jZed]

$sth->execute($username); ... DBI should escape the underscore in the code above, correct?

No, not correct. Neither DBI nor Pg should automatically escape underscores since there's no way for them to know when you mean a literal underscore and when you mean a wildcard. It sounds like you've had a frustrating time, my condolences, I've been there. But I usually find that when I start thinking "module Foo really sucks" where Foo is a widely used and heavily supported project like DBI or Pg, it's usually turns out to be more a reflection of my frustration level than of the project. Hope it all works out for you.

[Seumas]

No, I definitely wouldn't say DBI:: sucks. It's a great package and makes life tolerable.

I'm just frustrated that it isn't more simple to find some obvious answers sometimes. It isn't like I didn't search the postgresql and DBI documentation and postgresql mailing list archives for an answer (and ask for help in #postgresql) - yet the only answer I could find was the regex solution!

In fact, now that I know better, it's clear that the answers to people in the mailing lists that I read themselves were also wrong. Self-education is often frustrating, but places like PM make it much easier... assuming one can overcome the fear of looking stupid for asking stupid or rudimentary questions. :)

Of course, now if anyone else has such a stupid question, they'll get the right answer here with the keywords "sql dbi insensitive" ;)

[hmerrill]

There are NO stupid questions! We've all been there ;-) It takes time to become familiar with the different pieces that make up a Perl Database application.

Be aware that using '~*' and '~~*' pattern matching in your queries is most probably a PostgreSQL-specific thingy. Just my personal opinion here, but I try to stay away from database specific functions because if at some point in the future you change your database from Postgresql to Oracle (or whatever), you'll have to redo that code entirely.

I try to stick with "standard" SQL and try to stay away from database specific functions. In this specific instance, the "lower" function will provide a database-independent way of doing a case-insensitive query. IMHO "lower" is a much better solution since it is database-independent.