Search Postgresql Archives

Re: bytea encode performance issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 6, 2008 at 9:16 AM, Sim Zacks <sim@xxxxxxxxxxxxxx> 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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux