Martijn Tonies wrote:

>> Well... as you see, we would need to find a solution for SQLDA thing.
>> The issue that we're having with our 31-character limit on the object
>> identifiers is directly related to this, since if we start passing
>> 128-byte-long table names, we can easy cause AV in client applications.
>> Same applies to extending XSQLVAR... we can't simply add new field to it
>> without changing the XSQLDA version, but if we do - we have to be sure
>> that every component suite is capable of supporting this.
>>
>
> Right, that's quite the change.
>
> Why not add this while at the same time allowing for 128 byte identifiers
> in Firebird databases as well?
>
>

Sorry about the scatter pattern to my comments. I'm on vacation on our
sailboat.

Rather than thinking about another bad SQLDA, why not think about a more
flexible version, possibly defined as a pure virtual C++ class, that
doesn't contain fixed length fields, doesn't have to be preallocated,
and can be compatibly extended when needed. As long as the new
object/structure is semantically equivalent to the old one, it can map
into the existing wire protocol, which has always been more flexible
that the actual API. The new structure, of course, could live along
side the previous revs of the SQLDA and would be purely client side.

As has been mentioned any number of times, the original DSQL interface
was lifted lock, stock, and barrel from DB2 circa 1985. We knew at the
time it was a terrible interface, but we cared more about compatibility
to a de facto SQL standard than something we could live with
indefinitely. Good motivation and logic, I think, but wrong answer.