From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Sim Zacks" <sim(at)compulab(dot)co(dot)il> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: bytea encode performance issues |
Date: | 2008-08-07 04:53:31 |
Message-ID: | b42b73150808062153i78a6fc8r5e612948c00286d3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Aug 6, 2008 at 9:16 AM, Sim Zacks <sim(at)compulab(dot)co(dot)il> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2008-08-07 04:57:52 | Re: Invocation overhead for procedural languages |
Previous Message | Tom Lane | 2008-08-07 03:50:57 | Re: lossing pg_stat's data |