> Hello Vlad,
>
>>>> Do you consider "too complex and not very intuitive" for data access
>>>> layer
>>>> to query system tables for fileds CHECK constraints, DEFAULT values, etc
>>>> ?
>>>
>>> This has nothing to do with fetching data. Having to query the
>>> system tables in order to properly process the data as provided
>>> by the client side API, does that sound "OK" to you?
>>
>> I never said it is OK. But i see nothing BAD so far.
>
> Your example was faulty.

Which example ? I'm lost in this flame ;)

>>We can't extend XSQLVAR
>> without API change and introduce of BIG headache for component writers.
>
> I can understand that.

Very good ;)

>>There
>> is well known and easy to implement workaround - use it.
>> Imagine we start to use sqlscale for N. It will be supported *only* by
>> fbclient v3
>> and fbserver v3 (or higher). I.e. it will not work if client or server
>> have version less
>> than 3. Imagine fb3 will be released at 01.01.2010. When you plan to
>> migrate to fb3
>> and use this feature ? Do you think component writers will be glad to
>> implement
>> additional check for versions of both client and server to decide if
>> sqlscale contains N ?
>
> Why is sqlscale only available in newer clients? It's available in the
> structure right
> now, can't it be filled?

It can be filled. But no component writers will use it as it give nothing
new for them. No, it gives - headache with determining if this field have
useful info or not.

> It is done before, passing a characterset or collation ID (?) for BLOB
> columns, for
> example, did this require a client library change?

Even if it not require change of client library (i didn't look at code) - it require
new server. When you start to use it ? In next 5 years after release ?

This is the common and much more important question than all said above,
IMO - when you (not you personally) will use, say, v2.1 ?

>> I prefer to make one big change to API in some version of FB than
>> introduce a lot
>> of little hacks in every release. The only exception is when there is no
>> workaround.
>
> When UTF8 support was introduced, was this considered the correct workaround
> to fetch CHAR data?

UNICODE_FSS exists far more longer than UTF8, so "issue" is not depends on UTF8.

> Funny to read that you consider fetching data from the server in order to
> support
> a client API not a "headache" for component writers or application writers.

Data access layers already do query system tables. It seems you think i
offer to read RDB$CHARACTER_SETS every time user query is executed ?
No, it is enough to read it one time and cache result at client side. It is simple,
not expensive and easy to do.

> Using
> "sqlscale" to pass N would be much easier on both.

Ask them.

> Heck, even if the component themselves do not use "sqlscale" to pass a
> spaced
> padded string of the correct length, the application writers can use it.

Application writers have more to do with application than with incomplete components.
For app.writer is much easy to use good written components than re-invent the weel.

Regards,
Vlad