Re: [Firebird-devel] ExprNode::FLAG_VALUE

2022-01-06 Thread Adriano dos Santos Fernandes
On 06/01/2022 09:53, Dmitry Yemanov wrote: > 06.01.2022 04:28, Adriano dos Santos Fernandes wrote: >> >> There is ExprNode::FLAG_VALUE ("Full value area required in impure >> space"), inherited from old (2.5) code base nod_value. >> >> It's set by sort subsystem and used only for parameters and

[Firebird-devel] ODP: ExprNode::FLAG_VALUE

2022-01-06 Thread Karol Bieniaszewski
Hi If i totally miss the point then ignore. Maybe it is becuse we can sort not only by fields but by any expression. We can sort by concatenation of strings, numbers and we can even sort by subquery like SELECT * FROM RDB$RELATIONS R ORDER BY (SELECT COUNT(*) FROM RDB$RELATION_FIELDS RF WHERE

Re: [Firebird-devel] ExprNode::FLAG_VALUE

2022-01-06 Thread Dmitry Yemanov
06.01.2022 04:28, Adriano dos Santos Fernandes wrote: There is ExprNode::FLAG_VALUE ("Full value area required in impure space"), inherited from old (2.5) code base nod_value. It's set by sort subsystem and used only for parameters and variables. Initially it as also used for fields. But at

Re: [Firebird-devel] Commit (un)certainity

2022-01-06 Thread Dimitry Sibiryakov
Mark Rotteveel wrote 06.01.2022 13:06: BTW: I think in most cases you should be able to infer from the socket error if the problem occurred on sending or on reading data (at least, when using blocking socket reads/writes, not sure about non-blocking). It is not true:

Re: [Firebird-devel] Commit (un)certainity

2022-01-06 Thread Mark Rotteveel
On 2022-01-05 21:48, Jiří Činčura wrote: Yes. You probably have the same problem in your provider, no? The problem exists there. Same as with fbclient. But I don't explicitly solve it, application developer is responsible for handling such scenario (if ever). I agree. If the application