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
