Bruce Momjian wrote:
> That is also an excellent idea. Just convert their escape to \ inside
> the parser. Of course, they still have to use \\ to get a \, as in any
> string. Great idea.
You can even make it fully compliant if you want. (There are of course
backward compatibility problems. I'm not sure what the Postgres policy is
on this.)
- If the escape character is backslash, do nothing.
- Otherwise, turn all backslashes in the string to double backslashes.
- If the escape character is not set, stop here.
- Turn all occurences of the escape character into a backslash except
where the escape character is doubled, where it should be made into a
single occurence.
(Optionally, if "\n" is just an 'n' character, you can handle double
occurences of the escape character by turning the first one into a
backslash.)
Probably the best bet for PostgreSQL programmers is to always code Like
clauses with an ESCAPE '\' (or however its written).
I really wish they'd chosen a character other than underscore for the
"match one" wildcard... Is there any standard practice for seperating words
in table names?
-Z-
