Introducing a default VARCHAR length

[Mark Rotteveel]

Currently, Firebird doesn't have a default length for VARCHAR/CHARACTER
VARYING, { NCHAR | NATIONAL {CHAR|CHARACTER} } VARYING, and
VARBINARY/BINARY VARYING.

I propose to introduce a default length for all these types of 255, and
can do the necessary changes in parse.y to add it.

Why 255:

- Big enough for - I think - common use cases
- Big enough to cast from other (non-string) scalar types without truncation
- Small enough to not be excessive in storage use, and fits in an index
on page size 8192 with UTF8, with some room to spare (e.g. for compound
indices)
- 0xFF ;)

Why at all:

- Required by the SQL standard (see below)
- Allows things like CAST(something as VARCHAR) (see also second point
under "Why 255"), which can be a simplification for query generators
- Can result in simpler code for ad-hoc queries and such

Any objections if I go ahead and submit a PR for this?


For reference, the SQL:2023 standard requires such a default, as 6.1
<data type> defines:

"""
<character string type> ::=
[...]
| CHARACTER VARYING [ <left paren> <character maximum length> <right
paren> ]
| CHAR VARYING [ <left paren> <character maximum length> <right paren> ]
| VARCHAR [ <left paren> <character maximum length> <right paren> ]
| [...]

[...]

<binary string type> ::=
[..]
| BINARY VARYING [ <left paren> <maximum length> <right paren> ]
| VARBINARY [ <left paren> <maximum length> <right paren> ]
| [...]

[...]

<national character string type> ::=
[...]
| NATIONAL CHARACTER VARYING [ <left paren> <character maximum
length> <right paren> ]
| NATIONAL CHAR VARYING [ <left paren> <character maximum length>
<right paren> ]
| NCHAR VARYING [ <left paren> <character maximum length> <right paren> ]
| [...]
"""

With syntax rule 6 (for BINARY) and 7 (for VARCHAR/NCHAR VARYING)
specifying:

"""
6) If <maximum length> is omitted, then an implementation-defined
(IL007) <maximum length> is implicit.

7) If <character maximum length> is omitted, then an
implementation-defined (ID069) <character maximum length> is implicit.
"""

Mark
--
Mark Rotteveel

[Mark Rotteveel]

On 14/02/2026 10:55, 'Mark Rotteveel' via firebird-devel wrote:
> With syntax rule 6 (for BINARY) and 7 (for VARCHAR/NCHAR VARYING)
> specifying:

That should have been "... rule 6 (for VARBINARY) ..."

Mark
--
Mark Rotteveel

[Dmitry Yemanov]

Mark et al,

> Currently, Firebird doesn't have a default length for VARCHAR/CHARACTER
> VARYING, { NCHAR | NATIONAL {CHAR|CHARACTER} } VARYING, and VARBINARY/
> BINARY VARYING.
>
> I propose to introduce a default length for all these types of 255, and
> can do the necessary changes in parse.y to add it.
>
> Why 255:
>
> - Big enough for - I think - common use cases
> - Big enough to cast from other (non-string) scalar types without
> truncation
> - Small enough to not be excessive in storage use, and fits in an index
> on page size 8192 with UTF8, with some room to spare (e.g. for compound
> indices)
> - 0xFF ;)
>
> Why at all:
>
> - Required by the SQL standard (see below)
> - Allows things like CAST(something as VARCHAR) (see also second point
> under "Why 255"), which can be a simplification for query generators
> - Can result in simpler code for ad-hoc queries and such
>
> Any objections if I go ahead and submit a PR for this?
>
> For reference, the SQL:2023 standard requires such a default

Yes, it's Feature T081, “Optional string types maximum length”.

In RDB, we've implemented it with a default length of 1024, because we
often see varchars of 200/300/500 in client databases, but quite rarely
> 1K. So while 255 is perfectly OK for non-strings and string
abbreviations, 1K looked fitting better for real-world string data (also
given that starting with v5 the unused tail is RLE-compressed to the
same final length for both 255 and 1024).


Dmitry

[Mark Rotteveel]

On 15/02/2026 06:30, Dmitry Yemanov wrote:
>> Any objections if I go ahead and submit a PR for this?
>>
>> For reference, the SQL:2023 standard requires such a default
>
> Yes, it's Feature T081, “Optional string types maximum length”.
>
> In RDB, we've implemented it with a default length of 1024, because we
> often see varchars of 200/300/500 in client databases, but quite rarely
> > 1K. So while 255 is perfectly OK for non-strings and string
> abbreviations, 1K looked fitting better for real-world string data (also
> given that starting with v5 the unused tail is RLE-compressed to the
> same final length for both 255 and 1024).

The downside of 1024 is that it doesn't fit in an index on page sizes
8192 with UTF8 and UNICODE_FSS, and 16384 with UTF8, (see
https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref50/firebird-50-language-reference.html#fblangref50-ddl-idx-maxstrnglgth)

We could consider 500, as that can fit. However, it would still mean
that with some collations it can't be indexed either as some collations
require 6 bytes per character, not 4 (see
https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref50/firebird-50-language-reference.html#fblangref50-datatypes-chartypes-charindxs).

A value of 339 or lower makes more sense to me, _if_ we want it to be
indexable.

Mark
--
Mark Rotteveel

[Dmitry Yemanov]

So the question is whether we want to see unconstrained VARCHAR always
indexable or not. I suppose we need more opinions on this. Comments
anyone else?


Dmitry

[Denis Simonov]

It seems to me that if an index is implemented on the initial part of a VARCHAR, 

limited to N characters, then longer VARCHARs by default won't be such a big deal. 

Limited indexes can always be created for them.

понедельник, 16 февраля 2026 г. в 15:26:58 UTC+3, Dmitry Yemanov:

[Vlad Khorsun]

16.02.2026 14:26, Dmitry Yemanov:

I prefer to have not big default, 255 or less. Yes, large strings with empty tail
compressed better now, but don't forget about memory usage. Including sort and hash
tables (for joins) usage.

Regards,
Vlad

[Dmitry Yemanov]

16.02.2026 16:06, Denis Simonov пишет:

>
> It seems to me that if an index is implemented on the initial part of a
> VARCHAR,
> limited to N characters, then longer VARCHARs by default won't be such a
> big deal.
> Limited indexes can always be created for them.

I suppose you speak about this:
https://github.com/FirebirdSQL/firebird/issues/2629

But such indices cannot support constraints.


Dmitry

[Denis Simonov]

OK. Then 255 characters does seem like a good choice. 

As for increased memory consumption, if the database designer is truly concerned about it, they won't use the VARCHAR type without a length limit.

понедельник, 16 февраля 2026 г. в 16:13:06 UTC+3, Dmitry Yemanov:

[Mark Rotteveel]

Preparing the PR, I noticed that in parse.y, for VARBINARY only (in rule
binary_character_type), it sets

```
$$->length = (USHORT) $3 + sizeof(USHORT);
```

It doesn't do that for VARCHAR nor NCHAR VARYING.

So, is this even necessary, and if so, should I add it too for VARCHAR
(rule character_type) /NCHAR VARYING (rule national_character_type), and
if not, should I remove it as unnecessary code?

Mark
--
Mark Rotteveel

[Dimitry Sibiryakov]

'Mark Rotteveel' via firebird-devel wrote 17.02.2026 9:11:
> So, is this even necessary, and if so, should I add it too for VARCHAR (rule
> character_type) /NCHAR VARYING (rule national_character_type), and if not,
> should I remove it as unnecessary code?

Yes, this code is necessary because it directly sets the character set id,
while code for other types set charset name, so the field length can be
calculated only after charset name lookup.

--
WBR, SD.

[Mark Rotteveel]

Ah, OK, that makes sense. Thanks.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

I think the discussion ran its course with most agreeing on a length of
255 (or less), so I created the PR:

https://github.com/FirebirdSQL/firebird/pull/8909

Mark

[Jim Starkey]

I don't have anything against a default varchar length, but it does
strike me as a proposal to embroider buggy whip handles. Inoffensive,
but it does really change anything.

Bounded string types, char and varchar, go back to the era of my youth
when memory was measured in K, disks in megabytes, and processor cycle
times in microseconds.  The machines that roamed the earth with SQL was
invented couldn't power a modern parking meter.

Has anyone taken a serious look at extending Firebird to support an
unbounded "text" type?  Sure, there are ramifications all over the
place, but the only hard problem is getting over the bounded string
mindset.  Internally, the length could be a single byte encoding that
either specified the length or, for text over a specific length, the
number of length bytes.

Jim Starkey