Ah, now I understand what you mean that an empty table can explain the
difference between index and non-index.
But I still don't understand why the explicit cast solves the problem, even
when that is the same type and character set as the parameter already has.
Mark
----- Reply message -----
Van: "Adriano dos Santos Fernandes" <adrian...@gmail.com>
Aan: "For discussion among Firebird Developers"
<firebird-devel@lists.sourceforge.net>
Onderwerp: [Firebird-devel] String error with actual snapshot of 3.0
Datum: do, jan. 7, 2016 18:00
On 07/01/2016 14:44, Mark Rotteveel wrote:
> On Thu, 7 Jan 2016 13:05:30 -0200, Adriano dos Santos Fernandes
> <adrian...@gmail.com> wrote:
>> On 07/01/2016 08:52, Mark Rotteveel wrote:
>>> Maybe we should leave it at that, but to me the index <> no-index
>>> behavior
>>> seems to indicate there is a deeper underlying problem.
>> May be the "deeper" problem is that you call CHAR_TO_UUID in a select
>> without records?
> To make you happy I will also test it with data, but to be honest **that
> should not make a difference**, and I expect it won't as this was a real
> problem that somebody had, and they did have data.
...
>> And, of course, if it has index, it should be evaluated to find the key,
>> and otherwise, there is nothing to evaluate?
> That comment makes no sense. If there is no index it also needs to be
> evaluated. It then uses NATURAL instead of an index access to find the
> record(s) (or no records).
>
> And given there is a difference in behavior (and that difference is absent
> in older versions) it looks to me like Firebird, since 2.5.4, does
> something different when an index is present.
>
>
SQL> create table t2 (n1 integer primary key, n2 integer);
SQL> select * from t2 where n1 = 1 / 0;
Statement failed, SQLSTATE = 22012
arithmetic exception, numeric overflow, or string truncation
-Integer divide by zero. The code attempted to divide an integer value
by an integer divisor of zero.
SQL> select * from t2 where n2 = 1 / 0;
SQL>
I have nothing more to say, it's the same thing and so obvious. :)
> Whether or not my table has data or has no data, or has data but not the
> specified UUID, the query should work and return the expected results (even
> if that is no result).
>
> And on top of that, none of this explains why explicitly casting the
> parameter to a character set (eg ASCII or UTF8) makes the problem go away
> even though the actual parameter description clientside is exactly the
> same.
I think you should re-read my explanation.
When you have '1234567890' or '1234567890<more 30 spaces>' and cast both
to CHAR(10), both will have a CHAR_LENGTH = 10.
So, as I said, SQL_TEXT leave the interpretation of what is actual data
and what is a buffer space.
Instead of arguing on that and wait 10 years for a Firebird change, I'd
want to ask you and any component developer to switch SQL_TEXT described
by the engine to a SQL_VARYING and adjust the length.
For every parameter, Firebird has an internal descriptor, and from some
time (maybe 2.1.X - CORE-2606 - not sure), that descriptor of external
SQL_TEXT is internally stored as VARCHAR, to allow you to use
SQL_VARYING and avoid problems.
Adriano
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
