On Wed, Aug 6, 2008 at 9:16 AM, Sim Zacks <[EMAIL PROTECTED]> wrote: > We are using UTF-8, and I am testing SQL-ASCII at the moment. DBMail is > a pre-built application, so until I am ready to start playing with its > internals I don't really have a choice about a number of its features. > The reason for the bytea is because of the multiple encodings, I have > suggested using SQL-ASCII to them and then it will be possible to use a > text datatype. > I don't know the reason for using the encode, I assumed that it was > because bytea wouldn't take a LIKE, but I see that I was mistaken. It > could be that in an earlier release LIKE was not supported against > bytea, but I don't know that for sure.
I don't quite follow that...the whole point of utf8 encoded database is so that you can use text functions and operators without the bytea treatment. As long as your client encoding is set up properly (so that data coming in and out is computed to utf8), then you should be ok. Dropping to ascii is usually not the solution. Your data inputting application should set the client encoding properly and coerce data into the unicode text type...it's really the only solution. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
