problem report and fix by lubomir.benes on the  h2 mailing list

Date parsing logic assumes that the calendar type is Gregorian, so it should use the Gregorian calendar even if the default locale says otherwise.

Fixes #675

on table containing more than one LOB column

This reverts commit e26337e9.

seems to cause various unit test failures.

This reverts commit e26337e9.

seems to cause various unit test failures.

I'm not sure why there is a reference to Oracle in the discussion of https://github.com/h2database/h2database/pull/451. Oracle does not support an enum type (although it can be emulated, as in any database, using a `CHECK` constraint).

Updated changelog

(MySql/ORACLE - SQL style)

Command failed silently corrupting the changed column.
Before the change (added after v1.4.196) following was observed:
 alter table T modify C int null; -- Worked as expected
 alter table T modify C null;     -- Silently corrupted column C

we removed this a long time ago

required passing the Column down to Value#convertTo
Note that the test code in testscript.sql was pulled from maxenglander's
PR #572

update docs to match code

this limit applies to both 32 and 64-bit VMs

When using CHAR(N) in PostgreSQL any inserted value smaller than N
characters will be right-padded with spaces to fill all N characters.
See: https://www.postgresql.org/docs/9.1/static/datatype-character.html

This change adds an additional Mode.padFixedStrings and set it to true
in the PostgreSQL Mode. Any value converted to a ValueStringFixed at
INSERT will be right-padded with spaces.

For additional infos see the H2 Google Groups post:
https://groups.google.com/forum/#!topic/h2-database/Luaxdrl137Y