I'm not sure this is technically feasible. Maybe instead their should be a clearer warning when running compressOld.php.

Warning is good to have.

But it is not enough. If somebody already has compressed previously database, then decides to use search plugin. One should be able to restore back plain revisions in db.

IMHO, since the user of the MediaWiki engine can see all information in plain text independently how it is stored in db, compressed or not, it should be possible to extract the information from db not just to show for user, but write back to db uncompressed.

For gzip, it looks quite simple, just to update text.old_flags along with text.old_text which should contain the text after extracting.

For concat, it looks more complicated, update text.old_flags along with text.old_text. But it looks the order of text records unpacking should be considered and started with reference to actual compressed content.

I could miss some details, because my knowledge of MediaWiki source is quite shallow.

Thank you

Hmm, would you like to write that code and maintain it? :) I'm not convinced that this is a common use case, but let's see...

Sorry, but I am not sure that it is realistic for me.

This requires to configure dev env for php, test, debug, investigate all the details, and check that I didn't broke anything. And I didn't code on PHP for a long time, just fix something here and there if needed.

Implementation of this feature request is completely different from posting feature request only.
I just investigated the code for compressOld.php to be sure that it is not possible to uncompress revision for now.

My previous comment was primarily the answer for the following:
"I'm not sure this is technically feasible."

Anyway, thank you

Example of use case when the feature may be very useful:
https://stackoverflow.com/questions/13572268/extract-compressed-text-from-mediawiki-database-with-php

I can't think of why this wouldn't be technically feasible. But I'm not volunteering to write a patch for it.