Hello, I was wondering about H2's behaviour for CHAR types, as documented here: http://www.h2database.com/html/datatypes.html#char_type
The documentation says, this type is supported for compatibility with other databases. To my knowledge, any of these RDBMS show the same truncation behaviour as H2: - MySQL (if PAD_CHAR_TO_FULL_LENGTH is not set to true) - SQLite - Sybase But none of these do. For these, a CHAR(3) value seems to always have 3 characters: - DB2 - Derby - HSQLDB - Ingres - Oracle - Postgres - SQL Server Is there a reason H2 prefers the less popular behaviour of CHAR(n)? Note, I found this on the roadmap: Compatibility for data type CHAR (Derby, HSQLDB). Issue 212. Maybe this is the same issue? Note also, that according to the SQL standard, the correct behaviour also depends on the collation, which in turn has an effect on ordering and comparison: http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt Chapter 4.2.1 states: A collation descriptor includes [...] whether the collation has the NO PAD or the PAD SPACE attribute And then chapter 11.30 <collation definition> ::= CREATE COLLATION <collation name> FOR <character set specification> FROM <collation source> [ <pad attribute> ] <pad attribute> ::= NO PAD | PAD SPACE Hope this helps! Cheers Lukas -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
