We have a major divergence between Vulcan and Nickolay's 64 bit work
that needs to be addressed immediately.

Blobs are passed over the API by blob_id, defined by the architecture to
be an opaque 64 bit quantity. In practice, the engine used the blob id
as a two 32 bit word structure. For existing blobs, the high order word
contained the relation id and the low order word contained the physical
record number of the blob. For newly created blobs, the high order word
was zero, and the low order words a pointer to an internal blob object.

Since a 64 bit address cannot be crammed into a 32 bit number, something
has to give.

Nickolay chose to make the second word of the blob id a union of a 32
record number and pointer (64 bits). The alignment rules force the size
of the structure to 128 bits.

I chose to retain the 64 bit blob id structure for backward
compatibility. For temporary blocks, I plan to use a 32 bit handle for
the internal blob.

What makes the issue urgent is the Gpre has been changed since I
checkout Vulcan to generate the new structure, which is incompatible
with Vulcan.

I think it is very important to maintain the Firebird API during the
transition and coexistence of 32 and 64 bit platforms. Gpre was
designed and implemented to generate cross platform code so that post
processed programs are themselves portable. Arbitrary changes to the
API break this philosophy. It is important that we define and control
our API to minimize cross platform difficulties. I think changing the
definition of blob id with nearly 20 years worth of installed based is
unwise.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376