Re: [Firebird-devel] Named parameters in client libraries
> Does it have something like JDBC's ParameterMetaData? No. Only https://docs.microsoft.com/en-us/dotnet/api/system.data.common.dbparameter?view=net-6.0#properties. But this is purely in hands of developer, no connection to what's in database. -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
Adriano dos Santos Fernandes wrote 19.08.2022 12:05: So it would be something like COALESCE. I think that is the wrong approach for parameters. When deriving a type for COALESCE, it makes sense to infer the type to the widest possible type (VARCHAR) to allow all possible stored values to be represented, but with parameters, it is IMHO better to use the most specific type, as that will yield useful information to the user through the metadata, and probably result in the best diagnostic information when specifying invalid values. You prefer large over smaller VARCHARs, prefer TIMESTAMP over TIME - widest types But prefer TIMESTAMP and NUMBERS over VARCHAR - most specific I see no logic in your approach. It is on contrary. With COALESCE a datatype is chosen which every given datatype can be converted into. With parameters a datatype must be chosen which can be converted into any of given types. (Almost) any type can be converted to VARCHAR so it is a good choice for COALESCE. VARCHAR is hardly guaranteed to be converted into any datatype so it is a bad choice for parameters' common type. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 19-08-2022 12:05, Adriano dos Santos Fernandes wrote: You prefer large over smaller VARCHARs, prefer TIMESTAMP over TIME - widest types But prefer TIMESTAMP and NUMBERS over VARCHAR - most specific I see no logic in your approach. Most specific in the sense that a datetime type is more specific than a string type, for the TIME+TIMESTAMP+VARCHAR example: a TIMESTAMP value contains TIME, so covers both TIME and TIMESTAMP, and a TIMESTAMP is convertible to string, so can also be used with VARCHAR. On the other hand, not all string values are convertible to a TIME or TIMESTAMP value. On the other hand, maybe that could lead to other weird issues (e.g. consider a query TIME+VARCHAR that works fine, but stops working when TIMESTAMP is added in the mix. So, maybe using VARCHAR instead for those cases is the least intrusive alternative after all :( Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 19/08/2022 10:55, Adriano dos Santos Fernandes wrote: On 19/08/2022 06:06, Tony Whyman wrote: On 19/08/2022 00:42, Adriano dos Santos Fernandes wrote: On 18/08/2022 18:53, Tony Whyman wrote: IBX for Lazaus follows the original Deplhi IBX approach of adopting PSQL syntax for named parameters. Can a name be used more than once, and if yes, how is its type deduction? Adriano Uniqueness of parameters names is not required. If you have two or parameters with the same name in a given SQL Statement then both get set at the same time and to the same value. Type conversions are an issue for Firebird rather than IBX and are handled identically to positional parameters. Can't the user's library inspect parameters and its type? If yes, how would it be returned if a parameter name is used more than once with different Firebird types deduced in the different question-marks generated? The user can always check the current SQL Type of a parameter and use the setter they believe is most appropriate. If they insist on giving the same parameter name to two or more different parameters with differing SQL types - then that's their problem. The ByName method only ever returns the first parameter with a given name in position order. If the user calls its setter then the same value is given to all parameters with the same name. If there are no type compatibility problems then it works. If there are type compatibility issues then an exception occurs when they execute the query. The correct solution is to use different parameters names and set each parameter appropriately. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 19/08/2022 05:09, Mark Rotteveel wrote: > On 19-08-2022 02:36, Adriano dos Santos Fernandes wrote: >> On 18/08/2022 04:37, Mark Rotteveel wrote: >>> In other words, most specific type with the highest >>> precision/scale/length. When confronted with combinations of non-string >>> types and string/blob types, use the most specific non-string type. >> >> I don't think this is correct, specially the ones I listed above. >> >> 1: I would define it as VARCHAR with size using same rules of COALESCE >> with both types >> >> 5: same case as 1, VARCHAR >> >> 12: should be error, the two types are incompatible > > They shouldn't be according to section 4.6 of the SQL standard, > specifically Table 3 — Datetime data type conversions. > Conversion is a thing, but this is not about conversion. It's not logic for the case of parameters as well it's not logic in COALESCE. >> So it would be something like COALESCE. > > I think that is the wrong approach for parameters. When deriving a type > for COALESCE, it makes sense to infer the type to the widest possible > type (VARCHAR) to allow all possible stored values to be represented, > but with parameters, it is IMHO better to use the most specific type, as > that will yield useful information to the user through the metadata, and > probably result in the best diagnostic information when specifying > invalid values. > You prefer large over smaller VARCHARs, prefer TIMESTAMP over TIME - widest types But prefer TIMESTAMP and NUMBERS over VARCHAR - most specific I see no logic in your approach. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 19/08/2022 06:06, Tony Whyman wrote: > On 19/08/2022 00:42, Adriano dos Santos Fernandes wrote: >> On 18/08/2022 18:53, Tony Whyman wrote: >>> IBX for Lazaus follows the original Deplhi IBX approach of adopting PSQL >>> syntax for named parameters. >> Can a name be used more than once, and if yes, how is its type deduction? >> >> >> Adriano > > Uniqueness of parameters names is not required. If you have two or > parameters with the same name in a given SQL Statement then both get set > at the same time and to the same value. > > Type conversions are an issue for Firebird rather than IBX and are > handled identically to positional parameters. > Can't the user's library inspect parameters and its type? If yes, how would it be returned if a parameter name is used more than once with different Firebird types deduced in the different question-marks generated? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 19/08/2022 00:42, Adriano dos Santos Fernandes wrote:
On 18/08/2022 18:53, Tony Whyman wrote:
IBX for Lazaus follows the original Deplhi IBX approach of adopting PSQL
syntax for named parameters.
Can a name be used more than once, and if yes, how is its type deduction?
Adriano
Uniqueness of parameters names is not required. If you have two or
parameters with the same name in a given SQL Statement then both get set
at the same time and to the same value.
Type conversions are an issue for Firebird rather than IBX and are
handled identically to positional parameters.
The general algorithm for SQL statement execution is:
1. Parse the statement replacing named parameters with '?' placeholders
and create a name to parameter position index.
2. Call Firebird to prepare the query.
3. Set up a parameter array data structure using the Firebird input
parameter metadata, indexed by both position (integer) and name.
4. The user sets parameter values in any order. There are as many setter
methods for a parameter as types available (e.g. AsString, AsInteger,
AsFloat, AsDateTime, etc). The parameter's SQL Type is originally
derived from the Firebird metadata but may be overridden at this point
if the setter used is for a different SQL Type. For string setters, the
Pascal AnsiString type includes the codepage identifier (UTF8 is a
codepage for this purpose), and this is used to set the parameter's
character set id.
5. Immediately prior to executing the query, the input parameter
metadata is regenerated from the current SQL Types in the parameter
array, and the parameter buffer is packed using the regenerated metadata.
6. The query is executed. Any type conversion problems are reported back
by Firebird and result in an exception.
Note that batch queries are handled similarly to the above, except that
from the second row onwards, the same setter method must be used for
each parameter as was used for the first row - otherwise an exception is
raised.
A simple example (note IAttachment, etc. are Pascal interfaces (managed
types) and not the same as the firebird.pas types):
procedure DoQuery(Attachment: IAttachment);
var Transaction: ITransaction;
Statement: IStatement;
begin
Transaction :=
Attachment.StartTransaction([isc_tpb_write,isc_tpb_nowait,isc_tpb_concurrency],taRollback);
Statement := Attachment.PrepareWithNamedParameters(Transaction,'INSERT INTO
EMPLOYEE (EMP_NO, FIRST_NAME, LAST_NAME, PHONE_EXT, HIRE_DATE,' +
'DEPT_NO, JOB_CODE, JOB_GRADE, JOB_COUNTRY, SALARY) '+
'VALUES (:EMP_NO, :FIRST_NAME, :LAST_NAME, :PHONE_EXT, :HIRE_DATE,' +
':DEPT_NO, :JOB_CODE, :JOB_GRADE, :JOB_COUNTRY, :SALARY)');
with Statement.SQLParams do
begin
ByName('EMP_NO').AsInteger := 150;
ByName('LAST_NAME').AsString := 'Doe';
ByName('FIRST_NAME').AsString := 'John';
ByName('PHONE_EXT').AsString := '';
ByName('HIRE_DATE').AsString := '2015-4-1';
ByName('DEPT_NO').AsString := '600';
ByName('JOB_CODE').AsString := 'Eng';
ByName('JOB_GRADE').AsInteger := 4;
ByName('JOB_COUNTRY').AsString := 'England';
ByName('SALARY').AsFloat := 41000.89;
end;
Statement.Execute;
end;
Regards
Tony
Firebird-Devel mailing list, web interface
athttps://lists.sourceforge.net/lists/listinfo/firebird-devel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 19-08-2022 02:36, Adriano dos Santos Fernandes wrote: On 18/08/2022 04:37, Mark Rotteveel wrote: In other words, most specific type with the highest precision/scale/length. When confronted with combinations of non-string types and string/blob types, use the most specific non-string type. I don't think this is correct, specially the ones I listed above. 1: I would define it as VARCHAR with size using same rules of COALESCE with both types 5: same case as 1, VARCHAR 12: should be error, the two types are incompatible They shouldn't be according to section 4.6 of the SQL standard, specifically Table 3 — Datetime data type conversions. So it would be something like COALESCE. I think that is the wrong approach for parameters. When deriving a type for COALESCE, it makes sense to infer the type to the widest possible type (VARCHAR) to allow all possible stored values to be represented, but with parameters, it is IMHO better to use the most specific type, as that will yield useful information to the user through the metadata, and probably result in the best diagnostic information when specifying invalid values. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 18/08/2022 04:37, Mark Rotteveel wrote: > My guess is that they either: > > 1) don't allow mixing types > 2) use the most specific type that is compatible with all positions, > otherwise error > 3) use the first position > 4) use the last position > > I think rule 2 is probably the best, but I'm not really sure. > I think it's the only realistic way. > Some examples for rule 2 > 1) TIME, TIMESTAMP, VARCHAR(..) => TIMESTAMP > 5) VARCHAR(50), DOUBLE PRECISION => DOUBLE PRECISION > 12) TIME WITH TIME ZONE, TIMESTAMP WITHOUT TIME ZONE => TIMESTAMP WITH > TIME ZONE > ... > > In other words, most specific type with the highest > precision/scale/length. When confronted with combinations of non-string > types and string/blob types, use the most specific non-string type. I don't think this is correct, specially the ones I listed above. 1: I would define it as VARCHAR with size using same rules of COALESCE with both types 5: same case as 1, VARCHAR 12: should be error, the two types are incompatible So it would be something like COALESCE. I believe types would be computed in a first pass and in a later pass expressions already know the type of parameters. select * from rdb$database where 1 + :a = ? or 'x' || :a = 'xx' This would deduce :a to be a VARCHAR and the compilation would fail as 1 + VARCHAR is not allowed in compilation. I'm not saying it's easy to implement this, specially as I do not agree in many ways on how Firebird deduce parameter types now preferring to go longer in the AST. But I think is the logical way. If someone has an easier and logical approach I would love to know. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 18/08/2022 04:01, Mark Rotteveel wrote: > On 18-08-2022 04:02, Adriano dos Santos Fernandes wrote: >> How are client libraries (Jaybird, .NET Provider, Delphi ones) >> describing its named parameters to their users? >> >> I mean, given this SQL: >> >> select * >> from rdb$database >> where :param = 1 or :param = '2' >> >> We have here single name used in context with multiple types. >> >> I suppose you transform this to: >> >> select * >> from rdb$database >> where ? = 1 or ? = '2' >> >> Which will map to two Firebird parameters with different types. >> >> But for the user of the library, I suppose it's one parameter, correct? >> >> And what type (and the deduction rules) this parameter will be >> described as? > > JDBC doesn't define support for named parameters in > java.sql.PreparedStatement, only in java.sql.CallableStatement, which is > for calling stored procedures, and that support is optional, so Jaybird > doesn't have any support for named parameters. > > So, if Firebird is going to implement real named parameters, Jaybird is > probably not going to support them, and in that case I would really love > if this is controlled through a DPB item so when disabled, use of a > named parameter results in an error (e.g. "named parameters in DSQL are > not enabled" or something). Maybe I can then allow users aware of named > parameters to enable it explicitly to map it them themselves, for > example if something like `column1 = :param1 and column2 = :param2 and > colum3 = :param1` results in two parameters (param1 = position 1, and > param2 = position 2), and setting by position still works. > > The reason Jaybird probably is not going to support this, is because > most people don't use the JDBC API directly, but through things like > Hibernate, so adding vendor extensions to the JDBC API is pretty much > wasted effort because those libraries only use the JDBC API. I could add > such methods to the FirebirdPreparedStatement interface, but that would > then be a niche feature for people who do use JDBC, and are able to > unwrap to the FirebirdPreparedStatement interface (which is not always > possible when obtained from a connection pool). > > In the Java world, named parameters are usually emulated by layers like > Hibernate, or Spring's NamedParameterJdbcTemplate, which will map names > to positional parameters, and set the values of those positional > parameters appropriately. > It's sad that JDBC does not report names in ParameterMetaData. There is not much to worry for Jaybird. And there should not be a setting to disable it, specially in this case. We don't put settings to disallow MERGE, UPDATE OR INSERT, etc. Layers that do emulations in client could continue doing it and pass positional parameters to Firebird. I just hope they do it well. In node-firebird-driver-native, even which a submitted PR, I prefer to avoid do it in the client. Named parameters will continue to work in positional way too. If you have expression ":A = 1 or :B = 2 or :A = 3 or :C = 4", order of them will be "A, B, C". Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 18/08/2022 04:42, Jiří Činčura wrote: > In .NET parameters are named `@param`, aka the delimiter is `@`. > >> I suppose you transform this to: >> >> select * >> from rdb$database >> where ? = 1 or ? = '2' > > Correct. > >> Which will map to two Firebird parameters with different types. > > Correct. > >> But for the user of the library, I suppose it's one parameter, correct? > > Correct. Developer defines just `@param` and assigns value. > >> And what type (and the deduction rules) this parameter will be described as? > > Developer can set the type of parameter, which is later used to know how to > read it from it's value. For the describe this set of info_sql values is used > to get the info. Does it have something like JDBC's ParameterMetaData? If yes, how is the type of parameter names used more than once (comparing to different types) described? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 18/08/2022 18:53, Tony Whyman wrote: > IBX for Lazaus follows the original Deplhi IBX approach of adopting PSQL > syntax for named parameters. Can a name be used more than once, and if yes, how is its type deduction? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
IBX for Lazaus follows the original Deplhi IBX approach of adopting PSQL syntax for named parameters. For example:Select * From EMPLOYEE where EMP_NO = :KEYVALUE;It also allows for parameter names that are case sensitive and which contain special characters by enclosing the parameter name in double quotes e.g.Select * From EMPLOYEE where EMP_NO = :"Key Value";Named parameter handling takes place in the underlying Firebird Pascal API.Additionally, in IBX itself, the SQL update queries defined for a buffered dataset (TDataset descendents) allow parameter names to be preceded by "OLD_" or "NEW_". When a row in a buffered dataset is being edited, the original row values are saved and can be accessed using the "OLD_" prefix. The current values are returned by default or when "NEW_" is used as a prefix (effectively "NEW_" is not needed but included for completeness). e.g.UPDATE EMPLOYEE Set EMP_NO = :EMP_NO, FIRST_NAME = :FIRST_NAME where EMP_NO = :OLD_EMP_NO;The above updates the FIRST_NAME and the EMP_NO with any changes but always uses the old value of EMP_NO in order to update the correct row,If Firebird did support named parameters in a new version, I am not sure if this would be used by IBX. The code already works well and would have to be retained for the support of older versions of Firebird. The TDataset conventions would also have to continue to be supported.RegardsTony Whyman Original message From: Adriano dos Santos Fernandes Date: 18/08/2022 03:03 (GMT+00:00) To: For discussion among Firebird Developers Subject: [Firebird-devel] Named parameters in client libraries Hi Mark, Jiri, all!How are client libraries (Jaybird, .NET Provider, Delphi ones)describing its named parameters to their users?I mean, given this SQL:select * from rdb$database where :param = 1 or :param = '2'We have here single name used in context with multiple types.I suppose you transform this to:select * from rdb$database where ? = 1 or ? = '2'Which will map to two Firebird parameters with different types.But for the user of the library, I suppose it's one parameter, correct?And what type (and the deduction rules) this parameter will be described as?AdrianoFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-develFirebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
Mark Rotteveel wrote 18.08.2022 9:37: I'd suggest looking at what other database systems that do have named parameters currently do. My guess is that they either: 1) don't allow mixing types 2) use the most specific type that is compatible with all positions, otherwise error 3) use the first position 4) use the last position Oracle does not describe types of parameters at all requiring the user to assign them. Also it has some bugs in this area so two parameters with the same name cause mess and render whole case to be useless on practice. -- WBR, SD. Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
In .NET parameters are named `@param`, aka the delimiter is `@`. > I suppose you transform this to: > > select * > from rdb$database > where ? = 1 or ? = '2' Correct. > Which will map to two Firebird parameters with different types. Correct. > But for the user of the library, I suppose it's one parameter, correct? Correct. Developer defines just `@param` and assigns value. > And what type (and the deduction rules) this parameter will be described as? Developer can set the type of parameter, which is later used to know how to read it from it's value. For the describe this set of info_sql values is used to get the info. isc_info_sql_select, isc_info_sql_describe_vars, isc_info_sql_sqlda_seq, isc_info_sql_type, isc_info_sql_sub_type, isc_info_sql_length, isc_info_sql_scale, isc_info_sql_field, isc_info_sql_relation, // isc_info_sql_owner, isc_info_sql_alias, isc_info_sql_describe_end, isc_info_sql_bind, isc_info_sql_describe_vars, isc_info_sql_sqlda_seq, isc_info_sql_type, isc_info_sql_sub_type, isc_info_sql_length, isc_info_sql_scale, isc_info_sql_field, isc_info_sql_relation, // isc_info_sql_owner, isc_info_sql_alias, isc_info_sql_describe_end, -- Mgr. Jiří Činčura https://www.tabsoverspaces.com/ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 18-08-2022 04:02, Adriano dos Santos Fernandes wrote: And what type (and the deduction rules) this parameter will be described as? I'd suggest looking at what other database systems that do have named parameters currently do. My guess is that they either: 1) don't allow mixing types 2) use the most specific type that is compatible with all positions, otherwise error 3) use the first position 4) use the last position I think rule 2 is probably the best, but I'm not really sure. Some examples for rule 2 1) TIME, TIMESTAMP, VARCHAR(..) => TIMESTAMP 2) CHAR(5), VARCHAR(50), VARCHAR(100) => VARCHAR(100) 3) INTEGER, BIGINT, DECFLOAT => DECFLOAT 4) INTEGER, DATE => error: incompatible types? 5) VARCHAR(50), DOUBLE PRECISION => DOUBLE PRECISION 6) INTEGER, DOUBLE PRECISION => DOUBLE PRECISION 7) NUMERIC(4,2), NUMERIC(38,6) => NUMERIC(38,6) 8) NUMERIC(4,1), NUMERIC(4,4) => NUMERIC(9,4) (note the change in precision to accommodate range of values) 9) SQL_NULL (e.g. :param IS NULL), INTEGER => INTEGER 10) VARCHAR(..), BLOB => BLOB 11) BLOB SUB_TYPE TEXT, BLOB SUB_TYPE BINARY => BLOB SUB_TYPE BINARY 12) TIME WITH TIME ZONE, TIMESTAMP WITHOUT TIME ZONE => TIMESTAMP WITH TIME ZONE ... In other words, most specific type with the highest precision/scale/length. When confronted with combinations of non-string types and string/blob types, use the most specific non-string type. -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
On 18-08-2022 04:02, Adriano dos Santos Fernandes wrote: How are client libraries (Jaybird, .NET Provider, Delphi ones) describing its named parameters to their users? I mean, given this SQL: select * from rdb$database where :param = 1 or :param = '2' We have here single name used in context with multiple types. I suppose you transform this to: select * from rdb$database where ? = 1 or ? = '2' Which will map to two Firebird parameters with different types. But for the user of the library, I suppose it's one parameter, correct? And what type (and the deduction rules) this parameter will be described as? JDBC doesn't define support for named parameters in java.sql.PreparedStatement, only in java.sql.CallableStatement, which is for calling stored procedures, and that support is optional, so Jaybird doesn't have any support for named parameters. So, if Firebird is going to implement real named parameters, Jaybird is probably not going to support them, and in that case I would really love if this is controlled through a DPB item so when disabled, use of a named parameter results in an error (e.g. "named parameters in DSQL are not enabled" or something). Maybe I can then allow users aware of named parameters to enable it explicitly to map it them themselves, for example if something like `column1 = :param1 and column2 = :param2 and colum3 = :param1` results in two parameters (param1 = position 1, and param2 = position 2), and setting by position still works. The reason Jaybird probably is not going to support this, is because most people don't use the JDBC API directly, but through things like Hibernate, so adding vendor extensions to the JDBC API is pretty much wasted effort because those libraries only use the JDBC API. I could add such methods to the FirebirdPreparedStatement interface, but that would then be a niche feature for people who do use JDBC, and are able to unwrap to the FirebirdPreparedStatement interface (which is not always possible when obtained from a connection pool). In the Java world, named parameters are usually emulated by layers like Hibernate, or Spring's NamedParameterJdbcTemplate, which will map names to positional parameters, and set the values of those positional parameters appropriately. Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Named parameters in client libraries
Hi, last time I checked, IBExpert used the last parameter as reference, so it'll use a varchar(1)/char(1) . I followed the same pattern for the IBPP library bundled with Flamerobin when I added named parameters support, I wanted to convert correctly the parameter to its appropriate data type but lacked proper time and knowledge in C++ to guarantee every possible conversion properly so opted to keep it simple:\ At least from my previous tests with Delphi some component access automatically convert each time to its specific data type, no sure about other languages I could say each library uses a behavior they choose. On Wed, Aug 17, 2022 at 11:03 PM Adriano dos Santos Fernandes < adrian...@gmail.com> wrote: > Hi Mark, Jiri, all! > > How are client libraries (Jaybird, .NET Provider, Delphi ones) > describing its named parameters to their users? > > I mean, given this SQL: > > select * > from rdb$database > where :param = 1 or :param = '2' > > We have here single name used in context with multiple types. > > I suppose you transform this to: > > select * > from rdb$database > where ? = 1 or ? = '2' > > Which will map to two Firebird parameters with different types. > > But for the user of the library, I suppose it's one parameter, correct? > > And what type (and the deduction rules) this parameter will be described > as? > > > Adriano > > > Firebird-Devel mailing list, web interface at > https://lists.sourceforge.net/lists/listinfo/firebird-devel > Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
