Subject Re: [Firebird-Architect] Firebird 3 new features?
Author Jim Starkey
If the API is to be changed at all, it would make much more sense to get
rid of the damn SQLVAR structure for once and for all.

When I got my arm twisted to do DSQL at all, I adopted the DB2 API lock,
stock, and barrel, as a de facto standard that I wouldn't have to argue
about. A good strategy, perhaps, but a poor API.

Borland extended the SQLVAR to the XSQLVAR to pass more stuff without
considering that if they needed an extensions, somebody else would need
another, and maybe making an extensible structure would be great deal
smarter.

So if the binary API is going to be changed at all, please take the time
to make it better, not just a little bigger. There are gobs of ways of
doing this ranging from putting a structure length into the ZSQLDA
(marginal) to replacing a structure with calls to get individual data
items. The latter could be easily made backwards and forwards compatible.


Ann W. Harrison wrote:
> Roman Rokytskyy wrote:
>
>>> Would you care to clarify that? I'd really like to know why longer
>>> names cannot be done well.
>>>
>> Maybe because you would need to extend the XSQLVAR structure to include
>> schema name variable. Which is not backwards compatible.
>>
>>
>
> One could maintain the existing DSQL interface for applications that
> don't use schemas or long names and design a more flexible and forward
> looking version for V3. Or even just add a new version of the XSQLVAR.
>
> Best regards,
>
> Ann
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>


--
Jim Starkey
NimbusDB, Inc.
978 526-1376