The install SQL needs updated too if we go this route.

With that said, I'd rather keep the actual schemas as close to MySQL as possible. When I run these updates in bulk to sync things up, I have a couple of conversion scripts that do a bulk of the heavy lifting with me needing to do a couple other find/replace operations. I'd like to not lose little changes like this because of it.

I will update the install file as well.

Not sure if the proposed fix is acceptable or if something in the code needs to change.

It's acceptable in that it'll work, but like I said, I do have my concern for the future if someone's not paying attention. I do feel like something in the code may be missing though the more I look around; theoretically a similar issue should be present on other tables like com_content. So, maybe we did a code solution somewhere for other columns? I unfortunately don't have the time to chase that down tonight.

Hi guys,

So should we test this patch and merge now? Or do we wait for better solution?

Indeed, com_content had a similar issue and the tables remained unchanged. I was so far unable to find that specific bug report and fix (if there was one) to see what solution was applied.

So imo, we should look for another solution.

@vdespa I'm going to close this PR since it's targeted against a branch we're trying to delete.
Feel free to open a new PR against staging if you think the solution is appropriate.

Thanks!