This document doesn't replace documentation relevant to the database software you

are using, ie. README.mysql, README.pgsql or README.sqlite3.

Custom-defined primitives: SQL schema field name.

The field name of custom-defined primitives is derived from the primitive name, ie.

if, in a aggregate_primitives file, is defined a primitive with name 'blabla' then

it is expected the SQL schema will contain a field named 'blabla'.

Custom-defined primitives: SQL schema field definition.

The field definition should be worked out intuitively starting from the definition

of the primitive itself in the aggregate_primitives file. Following the SQL schema

(in MySQL format) worked out for the couple of examples provided as part of the

'examples/primitives.lst' doc:

name=mtla field_type=47 len=4 semantics=ip

Semantics is 'ip', so the field contains an IP address, length being 4 meaning only

IPv4 addresses are expected. The corresponding SQL field can be defined as follows:

"mtla CHAR(15) NOT NULL". If the primitive could encapsulate IPv6 addresses, the

field should be defined as CHAR(45).

name=mtlpl field_type=91 len=1 semantics=u_int

Semantics is 'u_int', so the field contains a positive integer number, length being

a single byte. The corresponding SQL field can be defined as follows: "mtlpl INT(1)

UNSIGNED NOT NULL".

name=custom_vlen_primitive field_type=43874:255 len=vlen semantics=str

Semantics is 'str', so the field contains a string of variable-length.

The corresponding SQL field can be defined as follows: "custom_vlen_primitive

VARCHAR(255) NOT NULL".

Custom-defined primitives: primary key and concluding remarks.

Custom-defined primitives can be no problem included as part of the primary key or

any other SQL table index. Inclusion is not any different from natively supported

primitives. For example a primary key including both 'mtla' and 'mtlpl' primitives:

"PRIMARY KEY (..., mtla, mtlpl, ...)".

Custom-defined primitives intuitively are not declared as part of any default table

version; although they will not fail version checks, it is recommended to set to

true the 'sql_optimize_clauses' feature.