On 15/08/2022 14:42, Vlad Khorsun wrote: > > I like the idea but not syntax. As already mentioned, there it will be > hard for > app\component devs to parse the whole statement looking for parameters. > Note, > semicolon usually mark "client" named parameters and it will be near to > impossible > for, say, Delphi components to correctly preprocess statement like below: > > execute sql (p1 integer = :p1) > do > select * from t where t.id = :p1 and t.name = :p2 >
Client parsers already need to stop at some place. But I understand what you mean, so just read below... > > You may expect after preprocessing by app it will be like: > > execute sql (p1 integer = ?) > do > select * from t where t.id = :p1 and t.name = ? > > > but actually it will be like: > > execute sql (p1 integer = ?) > do > select * from t where t.id = ? and t.name = ? > > without complex re-writing of existing preprocessors. > No, I expect that client parsers may not do unnecessary things, at least with this statement. We may report named parameters in the right way (currently EXECUTE BLOCK does not report then, do not know why). For the parsers using :name syntax, that's very easy. Just detect the new statement and do not pre-parse it. AFAIK .NET uses @name syntax. Since that is not a Firebird valid syntax, it should also not be difficult to detect and replace it. So this will not be processed by client at all. It will just read parameter names (p1, p2) from the described statement: execute sql (p1 integer = ?) do select * from t where t.id = :p1 and t.name = :p2 In fact the ugly "= ?" becomes completely unnecessary and better removed in this statement. And it's up to us to continue allowing unnamed parameters in this statement or not. I think we should and people using client libraries that require named (instead positional) parameters could just not use them. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
