Dmitry Yemanov wrote:

>>My opinion is that we should not go PostgreSQL way
>>introducing 50+ custom operators made of all combinations of
>>=, *, ~, ^, /, |, !, -, ?, #, &, <, >, @ etc.
>>
>>Oracle way of adding built-in functions seems like better idea to me.
>>Something like MODIFIED(A, B) returning TRUE if A differs
>>from B considering null as a special value seems to look better.
>>People can better read words instead of remembering 50
>>non-standard symbol combinations. Note that many people come
>>from C/C++ background and may start mismatching = and == in
>>expressions by accident. C/C++ would give a warning in such
>>cases while Firebird won't.
>>
>>
>
>100% agreed with Nickolay here.
>
>
>
>

There's a syntax problem with this. The statement "select * from xyz
where modified(a,b)" doesn't parse with the current grammer unless the
parse knows that "modified" is a boolean valued function rather than
scalar valued. On the other hand, building in a pseudo function doesn't
fit well with the meta-grammar (but could be done).

Other comparison operators are infix operators. An "equivalence"
operator should follow this pattern.

I don't buy the C++ argument at all. First, the semantics of the
proposed == is much closer to the C++ == operator than the C++ =
(assignment) operator. Second, the proposed == operator is what
programmers intend to write 95% of the time anyway. When comparing
against a literal, there is almost no difference. The only time that
significant differences can be expected is when it is used as a join
term, and in many case, it's also probably closer to what the programmer
intended. If a C++ programmer can master <> instead of !=, I think he
or she can back a == operator that behaves like a == operator.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



[Non-text portions of this message have been removed]