On Wed, Nov 13, 2013 at 4:01 AM, Dimitry Sibiryakov <[email protected]>wrote:
> 13.11.2013 9:17, Alex wrote:
> > For me main problem is that we do not know format of interbase messages
> > when boolean is used in them. We do not know alignment rules. We know
> > _nothing_ about internals of boolean implementation in interbase.
>
> Fortunately, we don't need to know all this to make boolean compatible
> from API POV.
> Client library will fill sqllen automatically, and even if rules differ,
> right application
> will handle this difference well.
Frankly, I don't see the problem with defining 590 to be boolean in
addition to the
Firebird specific boolean identifier. You wouldn't be guaranteeing
compatibility with
InterBase - that was abandoned in 2000. But at the same time, you wouldn't
be
blocking it arbitrarily. Those who want to walk on the wild side and mix
tools from
databases developed by different, non-communicating organizations should
expect
problems. When those problems occur, neither database is at fault. But
why put
in arbitrary roadblocks?
Maybe as a compromise Firebird could agree not to use 590 for anything but
boolean -
not saying that it be defined as boolean, but put a commit in the header
file saying that
590 is reserved for non-use.
Cheers,
Ann
------------------------------------------------------------------------------
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
