Database field type TEXT is too small; switch it to MEDIUMTEXT

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create and submit a form larger than 64k bytes.
2. Note error in dialog window:

Internal error "Data too long for column 'Form' at row 1".

Confirm with OK.

3. Note error on screen:

I’m sorry. I’m afraid I can’t do that; form form_save is an unsafe 
operation.

What is the expected output? What do you see instead?
I expected to have a bit more allowance for field content. 64k seems a little 
small; that said, this is the first time I've encountered the issue.

What version of the product are you using? On what operating system?
v4.5.4 (r4919) on Centos 5, MySQL 5.6.10

Please provide any additional information below.
Proposed solution would be to switch the database field type from TEXT to 
MEDIUMTEXT to allow field sizes of >64kb. My understanding is that MEDIUMTEXT 
permits field size of 16mb. I am willing to provide a diff if this is  a 
confirmed defect and the proposed solution is viable (i.e., no security 
repercussions, etc).

Original issue reported on code.google.com by gaek...@gmail.com on 23 Aug 2013 at 7:11

[GoogleCodeExporter]

Addendum - forum thread for background:

http://forum.textpattern.com/viewtopic.php?id=40006

Original comment by gaek...@gmail.com on 23 Aug 2013 at 7:12

[GoogleCodeExporter]

Form partials are presentational content. They contain template strings, but 
never content. These template strings should not be going over 64k characters. 
If they do, your template parser isn't enjoying itself, especially if the form 
partial is used in a loop (as a template for list items).

That said, normally MySQL should truncate any data that is too large for the 
field. The error should be because you are running MySQL in strict mode; strict 
mode, as the name states, is strict. In MySQL that means it stops the procedure 
on any 'issue' (where issue is anything where data would be subject to 
alterations) and signals about error.

The followed 'get_off_my_lawn' CSRF error is because the way 4.5.4 handles 
admin-side errors. It basically invokes the message even when it shouldn't. If 
I remember correctly, there too are process kill statements in one the error 
handlers - something you will not want; killing process can lead to actual real 
failures; any unfinished writes will not be written etc.

Maybe someday we will have field mappings, validation and exceptions (instead 
of absurd global error chains) so that this doesn't happen.

Original comment by jukka.m.svahn on 23 Aug 2013 at 1:36

[GoogleCodeExporter]

Thanks, Jukka. Is it relevant that the form was default (article) and not used 
in loop? Is that considered to be a partial?

Original comment by gaek...@gmail.com on 23 Aug 2013 at 1:46