Thread: CHAR SETS
Good day everyone I got a question, what are the differences of SQL_ASCII and UTF8, witch one should i use?? regards Cesar Alvarez.
Attachment
On Sat, Oct 13, 2007 at 11:23:41AM -0600, Cesar Alvarez wrote: > Good day everyone > > I got a question, what are the differences of SQL_ASCII and UTF8, witch > one should i use?? Well, SQL_ASCII means basically that what you put in you get out, but the DB is going treat it as ASCII, umlauts/etc simply won't be recognised. UTF8 means the DB will check your data is properly represented and make an effort to handle case-sensetivity and such things for you. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Attachment
Cesar Alvarez wrote: > I got a question, what are the differences of SQL_ASCII and UTF8, witch > one should i use?? SQL_ASCII is ASCII without encoding checks, UTF8 is UTF-8. I think that you should use UTF8. Yours, Laurenz Albe
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes: > Cesar Alvarez wrote: >> I got a question, what are the differences of SQL_ASCII and UTF8, witch >> one should i use?? > SQL_ASCII is ASCII without encoding checks, UTF8 is UTF-8. > I think that you should use UTF8. Pros: UTF8 will let you handle other character sets later on (though Postgres won't be able to provide locale support for more than one locale at the same time :( ) Cons: UTF8 is slower for many things, especially LIKE and regexp matching. If you have a very large database you may not be concerned with cpu usage though. It also requires extra indexes if you want to be able to use an index for LIKE. And you can't do substring() or length() on a very large datum without fetching the whole datum. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com