>> Also, I had plans to implement unlimited (well, OK, ULONG-counted) strings
>> in the next major ODS. This really requires more API changes than some hacks
>> with the sign bitWhen introduced then will be good to describe
>> benefits/weekness of using varchar vs blob in such case.Regards,Karol
>> Bieniaszewski
-------- Oryginalna wiadomość --------Od: Dmitry Yemanov <firebi...@yandex.ru>
Data: 22.05.2021 09:19 (GMT+01:00) Do: For discussion among Firebird
Developers <firebird-devel@lists.sourceforge.net> Temat: Re: [Firebird-devel]
Increasing CHAR/VARCHAR max. length to 64KB 22.05.2021 09:58, Mark Rotteveel
wrote:> In any case, I think adding 1 to a length to obtain the actual length
is > a bad idea even if it is not exposed to the outside. Doing that is a >
great way to introduce increased risk of off-by-one errors and buffer >
overflows; the risk of that increases exponentially when exposing this > to the
outside world.Agreed.> And what to think of 64KB record limitations, I seem to
recall being > told in the past that this is also a hard limit somewhere in the
legacy > API, which most people still use.I suppose you mean the API message
size limit. While the record size is also limited by 64KB, it has nothing to do
with the outside world and may be raised when needed.However, I do believe we
should implement a denser record compression *before* we increase either
VARCHAR or record length limits.Also, I had plans to implement unlimited (well,
OK, ULONG-counted) strings in the next major ODS. This really requires more API
changes than some hacks with the sign bit. > If we're going to break things
hard, I would sooner suggest something > a bit more radical and ambitious,
maybe something like SQL Server's > VARCHAR(MAX), or PostgreSQLs VARCHAR/BYTEA
(without length specifier), > and/or sending blobs inline in the wire protocol,
and maybe storing > blobs inline as well.I'd prefer to follow the standard,
with length treated as a constraint, and storage dependent on that length (like
we do for NUMERICs). But I don't mind having VARCHAR (without length specifier)
that's unconditionally backed by the ULONG-counted implementation.So I'd
suggest to start with the design for the "really long" strings and then decide
whether we should introduce it in v5 (for 64KB strings) or later (for 4GB
strings).DmitryFirebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
