TYPO3 Core

One can specify that in an extension's ext_tables.sql however.

Yes, of course. I only question the default column type. TYPO3 currently assumes that "varchar" is a safe default type if none other information is present for a single select field. However on other occurances it assumes TEXT as safe (types category, slug, group or non-singleSelect select, for example). So this is already inconsistent to other fields (including select itself!). The question is: why do singleSelect fields fall back to varchar in the first place? Personally, I'd prefer INT UNSIGNED, but at least to be consistent with all other fields it should be TEXT.

The reasoning is that select <option> fields rarely have big chunks of text in it? Varchars have index/storage advantages (with disadvantages too of course). This is a place where we can utilize it by "plausibility".

Garvin Hicking wrote in #note-3:

The reasoning is that select <option> fields rarely have big chunks of text in it? Varchars have index/storage advantages (with disadvantages too of course). This is a place where we can utilize it by "plausibility".

I know all of this. But then I ask the other way round, why is the global fallback for non-singleSelect select fields TEXT and not varchar? :) Of course, it is TEXT because of long CSV values exceeding 255 chars. So we have the case that select fields can be "anything", decided by non-obvious column config combinations, see also: #105441 (where null alongside only-ints is casted to varchar instead of int).

I don't enjoy the tone of the conversation. I'm leaving it for others to decide.

Georg Ringer wrote in #note-7:

hope you understand

I don't really care, after all some colum type has to be the default. ;) I just found it inconsistent that a select field can have three different SQL column type defaults, depending on not-really-documented combinations of the config options of select fields (the 1200 lines switch in DefaultTcaSchema.php of ext:core is the "documentation"). I'd expected selectSingle to be either UNSIGEND INT (because it usually holds a uid) or TEXT (the same fallback as other select fields have) -- but instead there pops up a VARCHAR (even if no dbFieldLength is specified!), that's all I questioned/wondered.