Search Postgresql Archives

Re: encoding aliases

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

 



On Wed, Mar 15, 2006 at 11:33:25AM -0500, Vivek Khera wrote:
> We're developing a DB that will be storing email messages.  The clear  
> winner for the DB encoding is UTF8.  However, I will need to set the  
> proper client encoding based on the encoding as defined in the email  
> message.

<snip>

Given that the messages directly encode both the encoding and the text
encoded, wouldn't make sense to store the emails in SQL_ASCII, i.e.
don't interpret the data at all, just consider it a bunch-of-bytes.

However, it seems what you're asking is as if you actually want to
interpret the content (i.e. you don't want to get out exactly what you
put in) and preserve semantics for easy searching, yes? I'm not sure
how to do that easily, since different parts of email can be in
different encodings.

To be honest, rather than relying on postgres behaviour, why not build
up a table mapping email encodings to postgres encodings. It costs
little but could save some hassle later on.

BTW, SQL-ASCII really means unknown encoding more than anything else...

Have a nice day,
-- 
Martijn van Oosterhout   <kleptog@xxxxxxxxx>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Attachment: signature.asc
Description: Digital signature


[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