Subject RE: [Firebird-Architect] Re: RFC: Please unify stored procedure execution
Author Samofatov, Nickolay

> > Jim said that current DSQL API is crap (probably he was
> in a hurry
> > designing it) but we have to live with it.
> Not Jims fault.... sorry. ISQL and the current DSQL
> implementation happened at Borland. Now that happened in my
> time, but I wasn't responsible for development then :-)

I have other data.
I see that Jim borrowed the DSQL API specification from IBM and it was
not very extensible.

It is interesting to see how it evolved at IBM now.

Now they have things like that (snippet from DB2 API header):
struct sqlda
unsigned char sqldaid[8];
long sqldabc;
short sqln;
short sqld;
struct sqlvar
short sqltype;
short sqllen;
unsigned char *sqldata;
short *sqlind;
struct sqlname
short length;
unsigned char data[30];
} sqlname;
} sqlvar[1];

struct sqlvar2
{ struct
{ long sqllonglen;
char reserve1[28];
} len;
char *sqldatalen;
struct sqldistinct_type
{ short length;
unsigned char data[30];
} sqldatatype_name;

#define SQLDASIZE(n) (sizeof(struct sqlda)+(n-1) * sizeof(struct

/* Macros for using the sqlvar2 fields. */

/* '2' in the 7th byte of sqldaid indicates a doubled number of */
/* sqlvar entries. */
/* '3' in the 7th byte of sqldaid indicates a tripled number of */
/* sqlvar entries. */
#define SQLDOUBLED '2'
#define SQLSINGLED ' '

From brief review of header, they apparently encode pointers to long
identifier names in equivalents of sqlname, relname, etc.
Depending of statement type number of SQLVAR entries varies and doesn't
match number of columns. Additional SQLVAR entries are used to return
additional data for the row, such as blob lengths, starting chunks of
blob data, record identifiers etc. Very ugly.

Firebird methodology to store blob collation in high-order bits of
descriptor flags is going to look like super-clean approach if compared
to this stuff.

> Paul