CHAR and VARCHAR page 2
Let us now see what happened with the definition of data. Below is a test script.
SQL Server 2008
So, only one row be inserted containing one character for each column. When you insert the remaining rows we get an error message:
String or binary data would be truncated. The statement has been terminated.
Although there is standard compliance, it seems to me that there is a contradiction that an explicit cast to the column type of the table does not work:
It may be noted the sequence in behavior: VARCHAR is arbitrary size; the second row was not inserted due to an error exceeding the size (ERROR: value too long for type character(1)); explicit value conversion to the column type of the table works, cutting off the extra characters from the right.
VARCHAR type is not supported without specifying the size of the string. CHAR corresponds CHAR (1) – as standard. Since the explicit conversion to CHAR leaves the length of the string without changing, then into the table, defined as
in the result, as in SQL Server, single row will be added:
Conclusions. In my humble opinion, none of these databases does not meet the standard behavior in those cases where the size of type is not specified. In my opinion, PostgreSQL is most consistent in the “particular implementation”. In order to code portability, I would recommend that you always explicitly specify the size.