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
