On 2019-11-17 12:22, jerzyha@... [firebird-support] wrote:

> On Sat, 16 Nov 2019 10:29:44 +0100, Mark Rotteveel
> mark@... [firebird-support] wrote:

>> Because it is hard to do. A lot of internals in Firebird and its
>> clients
>> rely on this maximum size (hint: the number itself fits in a 2-byte
>> unsigned integer). It is not like you just need to update a
>> MAX_ROW_SIZE
>> constant and it is changed.
>
> I understand it's not trivial. But that's why there are new versions
> like 3, 4 or now 5 to avoid such limitations.

That is because there is a cost to everything, manpower is limited, and
other things are considered more important to do.

>> Consider that PostgreSQL has a limit of around 8KB (with its default
>> page size). However, PostgreSQL has the advantage that variable length
>> fields can be automatically stored out-of-line (ie basically as a
>> blob,
>> but that is transparent to the user).
>
> However, according to the documentation "row size" is much larger. But
> maybe I am misreading this information.
>
> https://wiki.postgresql.org/wiki/FAQ#What_is_the_maximum_size_for_a_row.2C_a_table.2C_and_a_database.3F

That is because that row size takes the out-of-line (toast) fields (max
1GB per field) into account. Out-of-line fields are similar to blobs,
but they are less intrusive because - as far as I know - within the
protocol they are communicated with the rowdata, instead of having to
fetch them individually like you need to do with Firebird.

Personally, I would prefer changes that make VARCHAR (and VARBINARY)
practically unlimited and have Firebird do similar tricks like
PostgreSQL to automatically store as a blob if a value is too long, but
continue to communicate the data in-band in the protocol itself.

Mark