> 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
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
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
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
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
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
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
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
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
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
>>
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.
>
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
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
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
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
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)
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
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
18 matches
Mail list logo
