My fault. As Ann will explain, I was a child of the bit depression,
having spent too much time working in a 64K PDP-11 address space.

The difficulty is that Firebird has the system table metadata hardwired,
so changing the core system tables is somewhat problematical, but not
impossible.

For what it's worth, in Netfrastructure/Falcon was to populate in-memory
core system table metadata from embedded SQL DDL statements executed
during start up. Subsequent (internal) changes to system tables,
including the core system tables, could then be handled with the regular
versioning mechanism.

I agree whole heartily that 16 bits aren't nearly enough. In Falcon, I
learned that 32 bits weren't enough, either.

There are almost certainly a hundred other places where I scrimped on
word size -- when I wrote the original code, workstations maxed out at 3
MB and servers at 7 MB, so every bit saved in metadata went to
increasing the page cache size. Life is different now.

On 6/7/2013 2:34 PM, hi.egor wrote:
>
> From the first look at the system tables and their relations the
> reason of this limit is related to the datatype SHORT of column
> RDB$RELATION_ID of table RDB$RELATIONS and other related columns from
> tables ("RDB$DATABASE", "RDB$FORMATS", "RDB$PAGES"). Also I noticed
> that relations between different internal DB objects (such as columns,
> tables, indexes) are based on the "Table Name" (RDB$RELATION_NAME),
> but not "Table ID" (RDB$RELATION_ID). Looks like the primary used of
> RELATION_ID is to identify the PAGE in the data file.
> Consider these thoughts it seems to be not such a big and complex task
> to change SHORT datatype to for example LONG for RELATION_ID column
> (and related to it source code) to increase the maximum number of tables.
>
>



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