Kepler

I'd recommend not specifying the length for the VARCHAR - then it will use the maximum. Just omit the (500) or (1000) since, as you say, the dependency list is arbitrarily long and we might as well exhaust the capability of the DB before erring out.

http://www.hsqldb.org/doc/guide/ch09.html

some dbms support an unlimited length, indexed type for strings (such as 'text' type in postgres) that is a lot more flexible than using varchar. Have you considered using 'text' for databases that support it?

http://developer.postgresql.org/pgdocs/postgres/datatype-character.html

I've found another 255-char limit truncation issue, but this issue does affect our default hsql provenance dbs: parameter's value column gets chopped off at 255. This is far too small for e.g. a String Constant with value set to a large block of text. Apparently hsql is enforcing varchar length for this column -- the only difference I notice between it and a varchar(255) column with length not being enforced is that it has Nullable set to true instead of false.

For reference I did find text confirming hsql doesn't necessarily enforce column size:
-------
HSQLDB databases are initially created in a legacy mode that does not enforce column size and precision. You can set the property: sql.enforce_strict_size=true to enable this feature. When this property has been set, Any supplied column size and precision for numeric and character types (CHARACTER and VARCHAR) are enforced. Use the command, SET PROPERTY "sql.enforce_strict_size" TRUE once before defining the tables.
http://www.hsqldb.org/doc/guide/ch09.html#create_table-section
-------

Now using "text" type where supported.

Original Bugzilla ID was 5302