Postgres which encoding

It is likely that these mechanisms will be revisited in future versions of PostgreSQL. One way to use multiple encodings safely is to set the locale to C or POSIX during initdb , thus disabling any real locale awareness.

PostgreSQL supports automatic character set conversion between server and client for certain character set combinations. PostgreSQL comes with some predefined conversions, as shown in Tabela To enable automatic character set conversion, you have to tell PostgreSQL the character set encoding you would like to use in the client.

There are several ways to accomplish this:. For example, to change the encoding to SJIS , type:. Using libpq functions. If the function successfully sets the encoding, it returns 0, otherwise For C or POSIX locale, any character set is allowed, but for other locales there is only one character set that will work correctly. On Windows, however, UTF-8 encoding can be used with any locale. Table shows the character sets available for use in PostgreSQL.

Not all client API s support all the listed character sets. Thus, this setting is not so much a declaration that a specific encoding is in use, as a declaration of ignorance about the encoding.

For example,. You can use --encoding instead of -E if you prefer longer option strings. If no -E or --encoding option is given, initdb attempts to determine the appropriate encoding to use based on the specified or default locale. You can specify a non-default encoding at database creation time, provided that the encoding is compatible with the selected locale:. Another way to accomplish this is to use this SQL command:.

Notice that the above commands specify copying the template0 database. While it is possible for PostgreSQL to communicate with your application using the latin1 encoding on the client side if the server side dataset includes texts in incompatible encodings, PostgreSQL will issue an error.

Such texts might be written using non-Latin scripts such as Cyrillic, Chinese, Japanese, Arabic or other languages. It must be noted that Unicode encoding makes comparing and sorting text a rather costly operation. That said being fast and wrong is not an option, so we are going to still use unicode text!