--- In IBDI@y..., Helen Borrie <helebor@d...> wrote:

> An old bug in IB has been tidied up. Here is an example (thanks,

Hans Hoogstraat):

>
> select a.compname from company a , employee b
> where a.compname = b.compname
> and b.empno = :empno
> order by compname
>
> The ambiguity here is that the statement does not identify which

table's compname to order by and the results are somewhat
unpredictable - contradictory, even, if you compare database versions.

>
> In Firebird, Claudio has tidied up the dyn code so that an ambiguity

such as this will be detected. Currently, it simply causes a silent
warning. The plan is to make it throw an error in Rls 2.

>
> However, there are voices in devel who would like to make even Rls 1

throw an error, rather than a warning which is not detectable.

>
> The effect of the change - when it happens - will be to cause

exceptions in your applications where you are using such ambiguous
statements.

>
> What we'd like discussed is whether you want to keep things the way

they are for Rls 1, knowing that the axe will fall in Rls 2; or
whether your preference is to bite bullet and have it activated now.

As you know, the SQL standard says an exception should be thrown in
this case.

My personal opinion, for what it's worth, is that you should activate
the "throw an exception" change sooner rather than later.

Sure, some applications might break, but that's probably a good thing
-- in my experience, there's a good chance that those applications
weren't working quite as well as people might have thought.

Forcing people to clean up that code now, rather than later, also
means (I think) that people won't just keep writing sloppy code and
have an even bigger job to clean up later on.

(And maybe I'm wrong, but I can't see many people bothering to go back
to their applications to add a check for whether the silent warning is
being thrown. Sounds like work to me :-)

Rambling off,
db