>> > While the application *can* get N by querying the charset system table,
>>
>> Why application ? It is job of data access layer\components.
>
> With "application" I meant "everything above fbclient", so it would
> include fibplus etc.

I prefer to not mix the things

>> > it is a rather complicated task
>>
>> Really ???
>
> Yes:
>
> 1. It requires an extra round-trip to the server, including execution of
> an additional SQL query. So for each query you have to execute another
> query just to be able to read the data from the first query correctly.

NO ! Read it *one* time and save for reuse.

> 2. It is not intuitive that the data returned from a query is not "self
> contained" but requires me to get other info "myself" to be able to read
> it correctly. Especially bad since the "problem" is very subtle and far
> from obvious until you stand there confused wondering why all your
> expected fixed-length data appear to be padded in a seemingly random manner.

The "issue" is obvious to anyone who attached with UNICODE_FSS to any
FB server, starting from 1.0

>> > and also not very intuitive that it is required.
>>
>> Do you consider "too complex and not very intuitive" for data access layer
>> to query system tables for fileds CHECK constraints, DEFAULT values, etc ?
>
> Most application don't query for that. They just pass data and handle
> any exceptions that result.

It seems we have used different components.

> So, yes, it is very complex in comparison.

Evaluate again ;)

Regards,
Vlad