--- In Firebird-Architect@yahoogroups.com, "Dmitry Yemanov"
<dimitr@u...> wrote:

> > Last time I was talking to Dmitry Emanov he told me this
> > Yaffil piece is still a little bit flacky to be ported into
> > Firebird safely at the moment.
>
> I don't want to port Yaffil's built-in functions, as their

implementation is quite complex and some bugs/limitations are still
there. This particular feature is quite trivial and I see no problems
porting it into v2.0. Let's just agree on the syntax.

PR: Perhaps the way I have added some Oracle built-ins (via the
blr_external verb) is a basis for adding new buit-in functions. The
Fyracle usage is PL/SQL specific and is 'proof of concept' quality,
but the ideas and concepts might work for Firebird built-ins too.

> > 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.

I guess in Oracle one would code for equivalence with a built-in
function:
DECODE(old.columnA, new.columnA, true, false)

> 100% agreed with Nickolay here.

I would not favour 50+ custom operators, but == feels nice.
Would "columna==NULL" be equivalent to "IS NULL columna" ?

Paul