[Firebird-devel] DSQL API (was Re: Parameterized Exceptions)

[Adriano d. S. F. <adr...@gm...>]

Dmitry Yemanov wrote:

> information being available during prepare. We provide some subset via 
> XSQLDA, but the rest should be retrieved via isc_dsql_sql_info().

Do not think this API is a model to discuss good architecture :-),
although this has nothing to do with the topic.

> In many cases it means an extra rountrip. And IMO this is perfectly okay.

I'd say the cost x benefit is so high. There was better way to do it in
the start.

> I don't think we should deliver (in advance) whatever information the 
> client may wish.
> 
When it offers a flexibility (allowing, well, requiring) you to pass a
output SQLDA in each fetch, it need to parse it and create messages  at
every function call. Seems the reason that Dimitry S. says DSQL queries
are much slower than BLR ones.

In GDS_DSQL_FETCH, this piece should be slow:
USHORT blr_length, msg_type, msg_length;
if (UTLD_parse_sqlda(status, &dasup, &blr_length, &msg_type,
	&msg_length, dialect, sqlda, DASUP_CLAUSE_select))
{
	return status[1];
}

And in the function start:
if (!sqlda)
{
	status_exception::raise(Arg::Gds(isc_dsql_sqlda_err));
}

I think we can allow DSQL_FETCH to be called with NULL sqlda when
DSQL_EXECUTE2 has been called with a non-null out_sqlda. In this case we
don't need to reparse it at every fetch.


And when the API allows you to be flexible and didn't it by default, it
makes queries that need (for example, the update count) to do another
roundtrip. Certainly a bad designed thing, hiding some bytes in most
queries but making the not-so-uncommon case much more slower.

This one I don't see a good way to fix without introduce new calls.


I had prototyped client PreparedStatement/ResultSet class that works
with the message API. It's much raw yet, but I believe it can be faster
than the SQLDA API due to the first issue.


Adriano