My high priority feature list for Firebird 3 is very short:

1. Two level name space (aka schemas)
2. Long identifiers (128 characters)
3. UTF-8 only ODS

A multilevel name space is necessary for standard conformance, but more
importantly, it is necessary to support multiple application instances
within a single database, a near absolute requirement for Web
applications. We can support multiple application instances now with
multiple databases, but at a huge overhead in resource usage. Much of
the implementation of multilevel name space is trivial -- extended BLR
to support qualified table name, jack up the language parser, add a
couple of lines to SQL pass1, and we're 95% of the way there. Well, not
quite. The sorry fact is that the XSQLDA doesn't support a scheme name
(it also has a hard wired 31 byte limit on table name). Unless we're
willing to switch to a new primary API (and I don't think we are or will
be), we will need to think long and hard about a transitional API that
can be efficiently implemented on the current, interim, and future
primary APIs. I believe this is IscDbc, but we need to decide this (or
not) as a project. There is no alternative to a tweak to the
SQLDA/XSQLDA/YSQLDA, but I'd rather hide this behind a better interface.

A habit we need break is dependence on fixed length strings internally
and across our interfaces. I'm not prepared (yet) to argue that the
database should only support the concept of "string", both for interface
design and internal coding, that's what we should assume.

If done in conjunction with the introduction of multilevel name spaces,
the introduction of long identifiers is trivial.

The issue of UTF-8 vs national character sets inside the engine is
critical, in my opinion, for three reasons. First, the constant
setting, checking, comparing, and looking up of character set has a
huge, huge overhead in performance. Second, the vast amount of code
inside the engine to manage national character adds great complexity to
the code base and increases the burden on developers. Finally, the
world is getting smaller, economies and cultures are getting
increasingly interlocked. The idea that particular database fields are
of a particularly character set is already obsolete. Collations are
critical, but character sets are no more than an annoying aspect of the
top layer of human interfaces. It's time to accept that we're all part
of the same world. And if it halves the size of the code and doubles
performance, we get a kicker to boot.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376