It provides a useful mitigation to dump/reload databases having rows in the 1GB-2GB range, but it works under these limitations:
- no single field has a text representation exceeding 1GB. - no row as text exceeds 2GB (\copy from fails beyond that. AFAICS we could push this to 4GB with limited changes to libpq, by interpreting the Int32 field in the CopyData message as unsigned).
This seems like worthwhile mitigation for an issue multiple people have hit in the wild, and more will.
Giving Pg more generally graceful handling for big individual datums is going to be a bit of work, though. Support for wide-row, big-Datum COPY in and out. Efficient lazy fetching of large TOASTed data by follow-up client requests. Range fetching of large compressed TOASTed values (possibly at the price of worse compression) without having to decompress the whole thing up to the start of the desired range. Lots of fun.
