Although in this case I would just run mysqldump with --skip-extended-insert so that it doesn't create such long lines.
Yes, I tried that. But there are tables like l10ncache or objectcache that store serialized objects which produce long lines even in that case. Still, I think that should be a recommendation for creating the dumps.
Do you really want to dump those caching tables?
Good question... I don't think it's generally necessary. But then again, I think there are two reasons why we should allow for dumps that contain these tables: * it's easy to use plain old mysql dumps. The easier we make it for developers to test their code, the better. An alternative would be to provide a dumper script that removes these tables or doesn't dump them in the first place. I could dive into that if people here think that's a better way to go. * maybe someone wants to write a regression test that reproduces some specific caching issue. I agree this is unlikely, most probably unit tests would be a better way here. But then again, the mechanism I am working on might be a possible basis for unit test resources as well. The point is (and I did not see that in my previous post) that even if I skip caching tables in the import, there is most certainly one other table which might exceed the 1024 byte limit and that is "text".
Cheers, Markus