On 14-11-2019 17:06, blackfalconsoftware@... [firebird-support]
wrote:

> What do you mean I am wrong?  I have merely re-iterated how all database
> engines I have worked operate.

Telling us how other engines work is not very relevant when discussing
Firebird, and when the **internal implementation** in Firebird is
different. And if you do make assumption based on other database
engines, then please at least say that you do that so it is clear where
your assumptions are going wrong.

Saying with conviction that something works a certain way when it is not
is not only annoying for us who do know the internals, but potentially
confusing for people who don't know the ins and outs of Firebird.

> And what you are saying is that a CHAR field in Firebird acts in the
> same manner as that of a VARCHAR field.  If that were the case there
> would be no difference in how they are used and no reason to have two
> different data types.

No, that was not what I said. You seem to be confusing user visible
behaviour with internal implementation details inside the Firebird
database engine.

User visible behaviour:
- CHAR: fixed width and shorter values are padded with spaces upto the
declared length
- VARCHAR: variable width (not padded)

Internal in-memory implementation:
- CHAR: fixed width and shorter values are padded with spaces up to the
declared length
- VARCHAR: 2 bytes with actual (byte) length and shorter values are
padded with NUL bytes up to the declared length

Internal storage implementation:
- for both same as in-memory, but with RLE applied to compress size

> Historically, in database development CHAR fields
> were most often used for small string fields that would most often have
> a predtermined length such as a unit code whereas VARCHAR fields were
> used for data where that size at update was not generally known but
> would not exceed an expected maximum.

Yes, and that is the user visible behaviour of those datatypes.

> Second, if you as Human, can observer the effects of processes being
> performed in milliseconds than you must have some level of magic on your
> side to be able to observe such differences.

You were the first and only one to bring this up, in your reply to Ann.
The way you reply suggests you are replying to something I said, which
is not the case.

But now that you bring it up again: a human can observe a performance
difference of a millisecond. Say the choice between CHAR or VARCHAR
could cause a millisecond difference per record (which it doesn't, but
lets assume for argument's sake), then you can observe this difference
when processing a sufficient amount of records (eg processing a 1000
records would yield a 1 second difference).

[..]

> And I was not telling Ann anything different.

Yes, which means that effectively you were mansplaining Ann, who worked
on InterBase and Firebird, and knows the internals, how you think
Firebird works. And Firebird actually doesn't work that way.

> This information is also within the links that were provided to me
> regarding the explanation between CHAR and VARCHAR fields in the
> Firebird developer guide...

IBExpert.net is not a Firebird website, it is a third-party that sells
Firebird and InterBase tools, and in this respect their documentation is
wrong.

Mark
--
Mark Rotteveel