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
