On 2019-11-17 12:22, jerz...@o2.pl [firebird-support] wrote: > On Sat, 16 Nov 2019 10:29:44 +0100, Mark Rotteveel > m...@lawinegevaar.nl [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
