Wedge

Me neither. :)

I can't seem to find anything which suggests mediumtext is any more vicious than a text is, bearing in mind the fact that a mediumtext requires 3 bytes per row rather than 2, which means an extra byte per message, so you've got the extra I/O impact.

But really, given the way that you can accidentally trigger the code internally to perform an ALTER TABLE on the messages table without being aware of it, I'd rather just make the switch, which would typically solve the problem, you only then hit the query packet limit, rather than some shorter arbitrary limit (and it means that to all intents and purposes, 0 really does mean no limit)

Have you ever seen many posts grow over 64kb..?

Not *many*, no.

However, there's all sorts of fringe problems.

1) Set a post length of 64000, create a post where you add 63999 characters. It will be checked, validated as being within the limit, then preparsed, whereupon it will get bigger in almost every case (e.g. the newline conversion) where now it might not fit in to the text buffer.

2) If you set a limit of 0, there is absolutely no check made on content length and posts will be truncated at 64K without any warning.

3) If you set the length to > 64K, the table will be adjusted without warning, which is a full table lock. There isn't even a reminder to put it in maintenance mode.

4) If you set the length to > 64K, then back afterwards, the table will be downsized, without any validation of posts' content, meaning that any posts > 64K, they will be truncated without warning.


Now, we have two choices. We can accept the extra byte per message, or we can implement measures to remedy all of the above.

Don't forget option 3, do nothing...

For my "money", option 1, an extra byte per row, has least impact.

I prefer option 2, but that means work that you may not be able to afford at this time. Least upsetting might be 1 as a stop-gap measure until 2 can be implemented (i.e., do it right eventually).