Open firebird-automations opened 14 years ago
Commented by: Cosmin Apreutesei (cosmin_ap2)
Any change we get this function in 2.5 ? Otherwise I need to recur to dirty tricks for infering the version, like checking if the fb_sqlstate() is present in the library, then I know it's 2.5+ and so DSQL_unprepare is also available. Small rope, but just enough to hang myself with. Evolving libraries must have this function, please don't ignore it :)
Commented by: Cosmin Apreutesei (cosmin_ap2)
Any chance this might get implemented before 2.5 final release? I think for 3.0 it might be too late, because I won't be able to reliably distinguish fbclient 2.x from 2.5. Update: sorry for the double post (please delete this message -- I wasn't able to see comments for some reason)
Commented by: @dyemanov
Nope, v2.5.0 Final is already signed off.
Commented by: Cosmin Apreutesei (cosmin_ap2)
I see. Any suggestion for checking the success/availability of DSQL_unprepare in the client library? Just trying to make the Lua binding work with as many versions of fbclient and fbembed as possible without exposing irrelevant details to the client API.
Commented by: @dyemanov
IIRC, the client library doesn't handle DSQL_unprepare at all, it just passes it through the wire "as is".
Commented by: @asfernandes
It seems there is not a good way to check if the unprepare didn't succeeded when not supported.
The only way seems to check an error in the reprepare. So, your client can cache this info and didn't do it again for the same database.
Submitted by: Cosmin Apreutesei (cosmin_ap2)
This feature may be needed for someone who writes a binding of the fbclient to some language. It's necessary for the binding to configure itself according to the capabilities of the client library without surfacing the details to the user API.
Example:
I want to know if the new efficient unprepare feature (isc_dsql_free_statement() with code 4) of the client API is available in the client library so I know if I am allowed to use it or not.