I know that encoding affects how the information is actually
stored (IE whether 'A' requires one byte or multiple bytes,
and what value those bytes have, depend on the encoding).
Yes. Encoding is the character-to-byte conversion algorithm.
For mono-byte encoding such as LATIN1, it's trivially
byte value = character number, but for UTF-8 it's more
You don't need to create a new DB cluster. You can use CREATE COLLATION in Postgres 9.1 or later. Example in the manual:
To create a collation from the operating system locale fr_FR.utf8
(assuming the current database encoding is UTF8):
CREATE COLLATION french (LOCALE = 'fr_FR.utf8');
Be sure to read the chapter Managing Collations in the manual to ...
No, you can't add custom languages to the SQL Server system.
An end user won't interact with the system as such: you'd implement multi-language within your database design/application. The system language is irrelevant.
The encoding defines the very basic rules how characters are represented in binary format (like @a_horse explains in his comment). It should be mentioned that the server encoding has to match the client encoding for successful communication. Postgres can translate if necessary, there is a dedicated setting client_encoding for this.
The locale is a superset ...
I personally hate having to join multiple tables to get the international variant of some text value so I make each attribute that needs to be internationalized either an XML column or a JSON column and then use the relevant functions to return the value that matches the language I need. This is an extremely extensible solution in the sense that you can add ...
With PostgreSQL you can simulate something like using views and environment variables.
create table books_ids(
book_id serial not null primary key,
author text not null);
create table books_titles (
book_id int not null references books_ids,
lang char(2) not null,
title text not null,
isbn text null,
primary key(book_id, lang));
insert into ...
Assuming that each month is universally identified by number (1 is January, 2 is February, etc.), it is useless to have a table that store the first twelve numbers, so you could have a single table, with the following attributes:
CREATE TABLE month_loc (
month_number INT NOT NULL,
name VARCHAR(200) NOT NULL,
Let's say you created the database with the below parameters:
And by create, I really mean create, from scratch. A DBCA custom database, or running CREATE DATABASE and dictionary scripts manually.
If this happened, these will be your database level NLS properties:
SQL> select * from nls_database_parameters
First of all, this is an error message from PostgreSQL, which is not the same as psql (the command-line client). The SET command sets run-time parameters of the Postgres server, which is completely independent from the client (psql in this case).
Either way, it works for me. Testing the standard distribution of Postgres 9.4.1 on a Windows client set to a ...
Giving next example:
create table a (id int, description text);
create table b (id int, lang text, description text, default_lang int);
insert into a values (1, 'Yo vivo en Barcelona');
insert into b values
(1, 'en-US', 'I am living in Barcelona', 0),
(1, 'es-AR', 'Yo vivo en Barcelona', 1);
If you table have a default text for the default language you ...
Your approach is the correct one if the typical workload consists of small transactions that access only a few rows at a time (OLTP).
The extra join won't hurt, because it will be a nested loop join. Databases are optimized for stuff like that.
Any small performance loss will be outweighed by the advantage of having foreign keys to guarantee data integrity....
"Territory" is essentially equivalent to country code or locale. This setting affects default behaviour of the database when handling the date format, as well as the default SYSTEM collation (sorting) in some locales. Note that the client locale overrides this, so, when connected to a database with territory ru from a client with a US locale, the default ...
Are you saying that every VARCHAR is latin1 today? But tomorrow you need utf8mb4?
Disable foreign keys
ALTER TABLE ... CHARACTER SET utf8mb4
Dump the schemas; manually change charset
dump data without schemas
on a fresh machine load schemas, then data
Caution: "the devil's in the details."
If you are ...
I think the answer is... Use MySQL to store dates/datetimes/timestamps in the limited formats that it provides, then use app code -- possibly some library in your app language -- to get at fancier formatting.
As a general rule, a database is responsible for storing; the application is responsible for formatting.
See also https://dev.mysql.com/doc/refman/5....
I found a workaround: the bug happens only if an earlier attempt to create a collation has failed. After a failure, the bug seems to keep happening until the server process is restarted. So to create the collation, you have to get it right from the start, or restart the process to try again. To restart a Docker container, use
docker restart $...
I'm afraid it's not possible - at least according to the documentation
Check this out here.
To enable messages to be translated to the user's preferred language,
NLS must have been selected at build time (configure --enable-nls).
All other locale support is built in automatically.
You have to configure the database when you install it. Is your ...
The problem is length or lengthb functions treat these special characters as 1 byte but write_text function (correctly) considers these as 2 bytes. Hence a mal-formed XML is sent to the server.
To resolve this error please use the following instead of the length / lengthb function.
lv_clob_length_bytes := utl_raw.length(utl_raw.convert(utl_raw.cast_to_raw(...