On 21-05-2021 22:39, Alex Peshkoff via Firebird-devel wrote:
On 5/21/21 9:06 PM, Mark Rotteveel wrote:
On 2021-05-21 16:51, Alex Peshkoff via Firebird-devel wrote:
We have one more unused value for size - zero, we do not support
characters with length == 0.
We may store logical data length - 1, this will make it possible to
have exactly 64Kb fields, which (I believe) can be useful in some
cases.
Please don't apply that sort of hacks. It breaks existing
implementations, and is extremely confusing.
Mark, I've never suggested to use that size coding at places visible to
users. Internal encoding used by engine can't break anuthing (at least
directly). Though I'm not sure what did you mean under existing
implementations, i.e. my answer can be incomplete.
What is the point of adding 65536 (or even 65535) byte varchars when
users cannot access them?
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.
In any case, your same post is also talking about SQLDA/XSQLDA, which is
represented in the protocol and used by client implementations.
You still need to communicate that length to the XSQLDA, which is
restricted to 16 bits, and in the actual data where also 16 bits is
used. In other words you cannot represent 65536 (0x10000) in those
structures, even if we ignore that sqllen is currently a signed 16-bit
instead of unsigned.
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.
And with existing implementations I mean things like older client
libraries, drivers like Jaybird, tools that use those libraries. Which
all expect parse or otherwise work under the assumption of signed 16-bit
integers, and definitely do not have an assumption of having to add 1 to
the sqllen value to obtain the actual length.
Having new features is nice, but if the majority of our users will not
be able to use them, what is the point of doing the work.
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.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
