All scalar types include a NULL value, which is internally represented as a valid domain value. For numerical types, this is the smallest value in the type's domain (i.e., the one omitted in the ranges given above). Arithmetic expressions that overflow may lead to returning the NULL instead.

The integer types align with the storage of 1, 2, 4, 8 and 16 bytes.

The numeric and decimal types are represented as fixed length integers, whose decimal point is produced during result rendering.

The types REAL, FLOAT and DOUBLE map to the underlying implementation system. No special attention is given to the value NaN.

MonetDB/SQL supports a rich set of time-related operations within the kernel. The starting point are SQL 92 and the ODBC time-related data types.  There are six basic types and operations on them:

A timestamp is a combination of date and time, indicating an exact point in time (GMT). GMT is the time at the Greenwich meridian without a daylight savings time (DST) regime. Absence of DST means that hours are consecutive (no jumps) which makes it easy to perform time difference calculations.

The local time is often different from GMT (even at Greenwich in summer, as the UK also has DST). Therefore, whenever a timestamp is composed from a local date and time a timezone should be specified in order to translate the local time to GMT (and vice versa if a timestamp is to be decomposed in a local date and time). To adjust the local time can issue a command such as SET TIME ZONE INTERVAL '1' HOUR TO MINUTE.

We provide predefined timezone objects for a number of timezones (see below). Also, there is one timezone called the local timezone, which can be set to one global value in a running MonetDB server, that is used if the timezone parameter is omitted from a command that needs it (if not set, the default value of the local timezone is plain GMT).

The value ranges and lexical denotations are defined as follows:

Min and max years. The maximum and minimum dates and timestamps that can be stored are in the years 5,867,411 and -5,867,411, respectively. Interestingly, the year 0 is not a valid year. The year before 1 is called -1.

Dates. Fall in a valid year, and have a month and day that is valid in that year. The first day in the year is January 1, the last December 31. Months with 31 days are January, March, May, July, August, October, and December, while April, June, September and November have 30 days. February has 28 days, expect in a leap year, when it has 29. A leap year is a year that is an exact multiple of 4. Years that are a multiple of 100 but not of 400 are an exception; they are no leap years.

Time. The smallest time is 00:00:00.000 and the largest 23:59:59.999 (the hours in a time range between [0,23], minutes and seconds between [0,59] and milliseconds between [0:999] ). Time identifies a valid time-of-day, not an amount of time (for denoting amounts of time, or time differences, we use here concepts like "number of days" or "number of seconds" denoted by some value of a standard integer type).

Timestamp. A valid timestamp is formed by a combination of a valid date and valid daytime. When creating a timestamp from a date and daytime, a timezone should be specified (if timezone is omitted, the local timezone is assumed). If a timezone is specified, it is used to convert the date and time in that timezone to GMT, which is the internal timestamp representation. One problem here is that the first hour after DST has ended (some Sunday night in autumn, generally), the time is set back one hour, so the same times occur twice. Hence two translations to a timestamp are possible for such date and time combinations. In those case, we act as if it was the first occurrence (still within DST).

For difference calculations between dates (in numbers of days) we use signed integer. Hence, the valid range for difference calculations is between -2147483647 and 2147483647 days (which corresponds to roughly -5,867,411 and 5,867,411 years).

For difference between timestamps (in numbers of milliseconds) we use 64-bit bigint. These are large integers of maximally 19 digits, which therefore impose a limit of about 106,000,000,000 years on the maximum time difference used in computations.

Gregorian dates.
The basics of the Gregorian calendar stem from the time of Julius Caesar, when the concept of a solar year as consisting of 365.25 days (365 days plus once in 4 years one extra day) was introduced. However, this Julian Calendar, made a year 11 minutes long, which subsequently accumulated over the ages, causing a shift in seasons. In medieval times this was noticed, and in 1582 Pope Gregory XIII issued a decree, skipped 11 days. This measure was not adopted in the whole of Europe immediately, however.  For this reason, there were many regions in Europe that upheld different dates.

It was only on September 14, 1752 that some consensus was reached and more countries joined the Gregorian Calendar, which also was last modified at that time. The modifications were twofold: first, 12 more days were skipped. Second, it was determined that the year starts on January 1 (in England, for instance, it had been starting on March 25). Other parts of the world have adopted the Gregorian Calendar even later.

MonetDB implements the Gregorian Calendar in all its regularity. This means that values before the year 1752 probably do not correspond with the dates that people really used in times before that (what they did use, however, was very vague anyway, as explained above). In solar terms, however, this calendar is reasonably accurate (see the "correction seconds" note below).

Timezones
The basic timezone regime was established on November 1, 1884 in the International Meridian Conference held in Greenwich (UK). Before that, a different time held in almost any city. The conference established 24 different time zones defined by regular longitude intervals that all differed by one hour.  Not for long it was that national and political interest started to erode this nicely regular system.  Timezones now often follow country borders, and some regions (like the Guinea areas in Latin America) have times that differ with a 15 minute grain from GMT rather than an hour or even half-an-hour grain.

An extra complication became the introduction of daylight saving time (DST), which causes a time jump in spring, when the clock is skips one hour and in autumn, when the
clock is set back one hour (so in a one hour span, the same times occur twice). The DST regime is a purely political decision made on a country-by-country basis. Countries in the same timezone can have different DST regimes. Even worse, some countries have DST in some years, and not in other years.

To avoid confusion, this temporal type module stores absolute points of time in GMT only (GMT does not have a DST regime). When storing local times in the database, or retrieving local times from absolute timestamps, a correct timezone object should be used for the conversion.

Applications that do not make correct use of timezones, will produce irregular results on e.g. time difference calculations.

Correction seconds
Once every such hundred years, a correction second is added on new year's night. This rule would seriously complicate the temporal type module (as then the duration of a day, which is now the fixed number of 24*60*60*1000 milliseconds, becomes parametrized by the date), it is not implemented. Hence these seconds are lost, so time difference calculations in milliseconds (rather than in days) have a small error if the time difference spans many hundreds of years.

We cannot handle well changes in the timezone rules (e.g., DST only exists since 40 years, and some countries make frequent changes to the DST policy). To accommodate this we should make timezone_local a function with a year parameter. The tool should maintain and access a timezone database. Lookup of the correct timezone would be dynamic in this structure. The timezone_setlocal would just set the string name of the timezone.

As of 2003 the SQL standard supports serial types (sequences). They are of particular use in auto-generating key values.A serial type is defined as a primary database object over any of the built-in data types. The NEXT VALUE operation generates the next value and can be used anywhere a value expression is allowed. Its name should be unique within the current schema. It can only be dropped when the tables mentioning it have previously been dropped.

Example. The example shown below introduces the column count, which is incremented with each row being added. It is conceptually identical to the value expression max(count)+1in each insert. The column info is a limited range with wrap around.The serial type as found in PostgreSQL and the auto_increment  flag as found in MySQL are both mapped onto a sequence type in MonetDB/SQL.

CREATE TABLE test_serial (
   d DATE,
   id SERIAL,  -- this will implicitly create a PKey. Use BIGSERIAL if you want the id to be of type bigint instead of int.
   count INT AUTO_INCREMENT,
   info INT GENERATED ALWAYS AS
        IDENTITY (
           START WITH 100 INCREMENT BY 2
           NO MINVALUE MAXVALUE 1000
           CACHE 2 CYCLE
)      );

Much like other primary database objects, the sequence type can be altered at any time as illustrated below.

sql>CREATE SEQUENCE "my_test_seq" as integer START WITH 2;
sql>CREATE TABLE test (t int DEFAULT NEXT VALUE FOR "my_test_seq", v char);
sql>INSERT INTO test(v) VALUES ('a');
Rows affected 1
sql>INSERT INTO test VALUES (10, 'b');
Rows affected 1
sql>ALTER SEQUENCE "my_test_seq" RESTART WITH (SELECT MAX(t) + 1 FROM test);
sql>INSERT INTO test(v) VALUES ('c');
Rows affected 1
sql>SELECT * FROM test;
+----+---+
| t  | v |
+====+===+
| 2  | a |
| 10 | b |
| 11 | c |
+----+---+

The functions sys.get_value_for('<schema name>', '<sequence name>') and sys.next_value_for('<schema name>', '<sequence name>') can be used to query the current value of a sequence. The difference is that next_value_for() also advances the current value of a sequence to the next value.  The SQL statement SELECT NEXT VALUE FOR <schemal name>.<sequence name> is an equivalent of sys.next_value_for('<schema name>', '<sequence name>'). The following queries demonstrate how these functions and statement work:

sql>CREATE SEQUENCE "myseq" AS INTEGER;
operation successful
sql>SELECT get_value_for('sys', 'myseq');
+------+
| L2   |
+======+
|    1 |
+------+
1 tuple
sql>SELECT next_value_for('sys', 'myseq');
+------+
| L2   |
+======+
|    1 |
+------+
1 tuple
sql>SELECT NEXT VALUE FOR myseq;
+------+
| L2   |
+======+
|    2 |
+------+
1 tuple
sql>SELECT get_value_for('sys', 'myseq');
+------+
| L2   |
+======+
|    2 |
+------+
1 tuple

JSON has become the de facto light weight data interchange format for many web applications. It has a simple hierarchical structure and supports a limited set of value types. JSON is a natural representation of data for the C family of programming languages.

JSON is supported in MonetDB as a subtype over type VARCHAR, which ensures that only valid JSON strings are added to the database.

Example: CREATE TABLE json_example (c1 JSON, c2 JSON(512) NOT NULL);

MonetDB supports most of the JSON path expressions defined in [ref]. It can be used to decompose the values into regular tables, which then act as an index. A limited set of operators are predefined in the SQL catalogue.

JSON path expressions always refer to a single JSON structure. The root of this structure is identified by the identifier '$', which is implicitly assumed in most expressions. Components of the JSON structure are addressed through the dot notation, i.e. representing child steps and array element access. The wild card can be used for child names and undetermined array indices.

An example JSON object used for these expressions [ref], more examples in the testsuite.

{ "store": {
    "book": [
      { "category": "reference",
        "author": "Nigel Rees",
        "title": "Sayings of the Century",
        "price": 8.95
      },
      { "category": "fiction",
        "author": "Evelyn Waugh",
        "title": "Sword of Honour",
        "price": 12.99
      }
    ],
    "bicycle": {
      "color": "red",
      "price": 19.95
    }
  }
}

The related URL data type is a subdomain over strings and represent valid Uniform Resource Locators.

Example: CREATE TABLE URL_example (c1 URL, c2 URL(512) NOT NULL);

A collection of functions are provided to create, validate and extract portions.

The data type  UUID  stores a Universally Unique Identifiers (UUID) as defined by RFC 4122, ISO/IEC 9834-8:2005, and related standards. It can be used as a global unique 128-bit identifier. UUIDs are generated by an algorithm that ensures an extreme low probability that two calls to the same create function will ever produce the same value. They are often used in distributed (web-based) systems for this reason.

A UUID is written as a sequence of lower-case hexadecimal digits, in several groups separated by hyphens, specifically a group of 8 digits followed by three groups of 4 digits followed by a group of 12 digits, for a total of 32 digits representing the 128 bits. An example of a UUID in this standard form is:

select uuid();
+--------------------------------------+ 
| uuid                                 | 
+======================================+
| 65950c76-a2f6-4543-660a-b849cf5f2453 |
+--------------------------------------+

The system function sys.uuid() generates a new uuid and returns the uuid.

The system function sys.isauuid(string) checks whether the string value satisfies the grammatical UUID structure and returns a boolean value.

You can use cast() or convert() to convert a valid uuid string to a uuid type.

select cast('26d7a80b-7538-4682-a49a-9d0f9676b765' as uuid);

select convert('83886744-d558-4e41-a361-a40b2765455b', uuid);

The SQL type inet describes IPv4 network addresses. The inet module contains a collection of functions that operate on IPv4 addresses.  The most relevant functions are the `containment' functions that deal with subnet masks.

The functionality of this module is greatly inspired by the PostgreSQL inet atom. It should be extended to also support IPv6.

The MonetDB kernel supports creation of user defined types, e.g. geometric types. The relationship between SQL and MAL world is expressed using an external name.

The implementation of new atomary types is best postponed until there is no other performance-wise acceptable solution. Addition of an atomary type in the kernel would be beneficial if it is also complemented with bulk-operations and when type specific optimizers could exploit their semantics.

The CREATE TABLE statement conforms to the full SQL standard. Tables are assigned to the current schema unless the schema name is explicitly given as part of the table name. Table names should be unique amongst those mentioned within the same schema and distinct from view names.

The derived (temporary) tables are either filled upon creation or automatically upon use within queries.

Temporary tables are stored automatically under the schema 'tmp'. Temporary local tables are limited to the client session. The qualifiers denote the actions taken during transaction commit over a temporary table. If the ON COMMIT clause is omitted then all tuples are dropped while retaining the structure. In most cases you would use: ON COMMIT PRESERVE ROWS

For using Loader functions we support the MonetDB specific CREATE table FROM LOADER syntax.

For merging partitioned table data we support the MonetDB specific CREATE MERGE table syntax.

For replicating table data we support the MonetDB specific CREATE REPLICA table syntax.

For distributed query processing we support the MonetDB specific CREATE REMOTE table syntax.

For data stream processing we support the MonetDB specific CREATE STREAM table syntax.

Regular SQL view definitions are supported.

A view can be seen as a stored SELECT query with a unique name. It can be used in queries at all the places where you can normally use a table name. Views are useful to reduce user query complexity as they can predefine joins, computations, derivations, aggregations, selections, conditions, ordering, etc in the view, so the user doesn't have to define them in the queries again and again. They are also very useful to standardise and simplify reporting.

Note: The "WITH CHECK OPTION" is accepted for SQL compliance but has no effect.

Note: Views do not contain or store data, so do not require disk space.

Limitations: Recursive views and reference-able views are not (yet) supported.
Updatable views are not supported, so it's not possible to insert, update, merge, delete or truncate data from a view.

Tip: to find out which user views are defined in the database run query:
  SELECT * FROM sys.tables WHERE type IN (SELECT table_type_id FROM sys.table_types WHERE table_type_name = 'VIEW')

A SCHEMA is a container for tables, views, indices, triggers, functions and procedures.  Schema access and modification is strictly controlled using the user role and authorisation scheme.

Every SCHEMA belongs to a database. One reason for organizing the logically separated data in schemas rather than databases is that in this way there will still be just one MonetDB process running.

The DEFAULT CHARACTER SET and PATH options are here for compatibility reasons with the the SQL standard, however they are not yet implemented. The default character set is UTF-8.

schema_name_clause:
   ident | [ ident ] AUTHORIZATION ident

The AUTHORIZATION option allows specifying the name of the user or the role that will own the schema. If omitted, the user who has executed the query will be the owner. The owner of the schema is allowed to create, alter and drop tables. With the AUTHORIZATION option, an explicit name for the schema is optional. If omitted, the schema automatically gets the name of the authorised user/role as its name.

Notes on schema creation:

1. The ownership of a schema can be assigned to only one user/role, and it can not be modified after its creation. Therefore, to share the ownership of a schema, one must assign the ownership of a schema to a role at the creation of the schema. Subsequently, the role can be granted to multiple users to own the schema. 
2. Only the 'monetdb' user and the 'sysadmin' role can create a new schema. Therefore, to allow other users other to create schema, the 'monetdb' user should assign the 'sysadmin' role to the intended users.

schema_element:
   grant | revoke | create_statement | drop_statement | alter_statement

schema:
  | DROP SCHEMA qname drop_action

drop_action:
   RESTRICT | CASCADE

The drop_action option is supported for compatibility with the SQL standard, however it is not implemented yet. Currently it runs with the CASCADE option, meaning that once a schema is dropped every object inside the schema is dropped as well, such as tables and functions. However objects that are dependent on the schema, such as users will not automatically be dropped and will stop the schema from being dropped as well. One can either ALTER the user and give it a different default schema, or to simply drop the user if it is no longer needed.

schema:
  | SET SCHEMA ident

When opening the database, by default the “sys” schema is set. Another automatically created schema is “tmp”, used for temporally local tables. It is not possible for a user to access the “tmp” schema of another user.

One can create a new schema using the CREATE command and change to it, by using the SET command. When creating a table without specifying the schema, the table will be created in the schema that is currently in usage. In order to create a table in a different schema, use the schema name as a prefix.

The objects created can be removed provided the authorization permissions are set. Note: If you do not specify the full signature of the function the DROP query will successfully execute if there is only one function with this name, if not the query is aborted. The DROP ALL is used to drop all the functions with the name specified in the query.

Data insertions

A table can be populated using an insert statement. It takes a table name and a value expression list. The expression result types should align with the columns in the table definition. Otherwise the column-value association should be explicitly defined using a column name list. Multiple rows can be inserted in a single statement.

The result of a query can be bulk inserted into a table, provided both source and destination are type compatible. Insertion of a table into itself effectively doubles its content, provided non of the table constraints is violated.

You must have INSERT privilege for the table. The creator/owner of the table will have INSERT privilege automatically.
The "WITH cte_alias AS SELECT_query" option is supported from release Apr2019 (11.33.3) onwards.

MonetDB/SQL does not support data insertions on views.

Data updates

The update statement syntax follows the SQL standard, but its semantics for bulk updates on keys may be slightly different than expected from other systems. In particular, the update implementation ensures that you can freely update any column without the danger of run-away values. MonetDB/SQL doest not support updates through views.

You must have UPDATE privilege for the table or column(s). The creator/owner of the table will have UPDATE privilege automatically.
The "WITH cte_alias AS SELECT_query" option as well table alias is supported from release Apr2019 (11.33.3) onwards.

MonetDB/SQL does not support data updates on views.

Data deletions

You must have DELETE privilege for the table. The creator/owner of the table will have DELETE privilege automatically.
The "WITH cte_alias AS SELECT_query" option as well table alias is supported from release Apr2019 (11.33.3) onwards.

MonetDB/SQL does not support data deletions on views.

To quickly delete all rows in a table use TRUNCATE TABLE.

You must have TRUNCATE privilege for the table. The creator/owner of the table will have TRUNCATE privilege automatically.

A 'CONTINUE IDENTITY' or 'RESTART IDENTITY' clause can be passed to restart or not an identity sequence if present in the table. Default is to CONTINUE IDENTITY sequence numbering.
The 'CASCADE' option instructs to truncate referencing table(s) also if the referencing table(s) have foreign key references to this table. The default behavior is 'RESTRICT'.

Note: it is possible to use TRUNCATE statements in a transaction and thus to roll back the effects of a truncate.

MonetDB/SQL does not support truncations of data on views.

When a query is created a table can be referenced in different ways, sometimes by its name or by a select query or a join result. Here is the syntax to refer to a table.

When no join_type is specified, INNER is assumed.

The SQL framework for table expressions is based on the select-from-where construct.

Since Apr2019 release (11.33.3), expressions are allowed in the GROUP BY clause. The same expressions can be used in the projection clause, if and only if they are literally equal e.g.: SELECT count(*)*(col1+col2) as total FROM t1 GROUP BY col1 + col2.

The WITH clause prefix (aka Common Table Expressions (CTE)) provides the mechanism to introduce temporary in-line view definitions:

The pattern matching operations are used over predicates. It is possible to compare them, see the differences between them, if a predicate is a sub-predicate of another, etc. The following syntax description cover all the operations supported by MonetDB.

SQL provides a method to aggregate over a series of related tuples. They are called window functions and always come with an OVER() clause which determines how tuples are split up over the window functions.The PARTITION BY clause within OVER divides the rows into groups that share the same values of the PARTITION BY expression(s). For each row, the window function is computed over all rows participating in the group. The order within a partition can be used as well.

Supported Window Functions:
    RANK() : BIGINT - Returns the rank number within a partition, starting at 1.
    DENSE_RANK() : BIGINT - Returns the rank of the current row without gaps, it counts peer groups.
    PERCENT_RANK() : DOUBLE - Calculates the relative rank of the current row: (rank() - 1) / (rows in partition - 1).
    ROW_NUMBER() : BIGINT - Returns the position of the tuple currently in the result set, starting at 1.
    CUME_DIST() : DOUBLE - Calculates the cumulative distribution: number of rows preceding or peer with current row / rows in partition.
    FIRST_VALUE(input A) : A - Returns input value at first row of the window frame.
    LAST_VALUE(input A) : A - Returns input value at last row of the window frame.
    NTH_VALUE(input A, nth BIGINT) : A - Returns input value at “nth” row of the window frame. If there is no “nth” row in the window frame, then NULL is returned.
    NTILE(nbuckets BIGINT) : BIGINT - Enumerates rows from 1 in each partition, dividing it in the most equal way possible.
    LAG(input A [, offset BIGINT [, default_value A ] ]) : A - Returns input value at row “offset” before the current row in the partition. If the offset row does not exist, then the “default_value” is output. If omitted, “offset” defaults to 1 and “default_value” to NULL.
    LEAD(input A [, offset BIGINT [, default_value A ] ]) : A - Returns input value at row “offset” after the current row in the partition. If the offset row does not exist, then the “default_value” is output. If omitted, “offset” defaults to 1 and “default_value” to NULL.
    MIN(input A) : A
    MAX(input A) : A
    COUNT(*) : BIGINT
    COUNT(input A) : BIGINT
    SUM(input A) : A
    PROD(input A) : A
    AVG(input A) : DOUBLE.

The supported frames are:
    ROWS - Frames are calculated on physical offsets of input rows.
    RANGE - Result frames are calculated on value differences from input rows (used with a custom PRECEDING or FOLLOWING bound requires an ORDER BY clause).
    GROUPS - Groups of equal row values are used to calculate result frames (requires an ORDER BY clause).

See also en.wikibooks.org/wiki/Structured_Query_Language/Window_functions

Examples:

create table ranktest (id int, k varchar(3));
insert into ranktest values (1, 'a'),(2, 'b'),(3, 'c'),(4, 'd');
insert into ranktest values (1, 'a'),(2, 'b'),(3, 'c'),(4, 'd');

select ROW_NUMBER() over () as foo from ranktest;
select ROW_NUMBER() over (PARTITION BY id) as foo, id from ranktest;
select ROW_NUMBER() over (PARTITION BY id ORDER BY id) as foo, id from ranktest;
select ROW_NUMBER() over (ORDER BY id) as foo, id from ranktest;

select RANK() over () as foo from ranktest;
select RANK() over (PARTITION BY id) as foo, id from ranktest;
select RANK() over (PARTITION BY id ORDER BY id) as foo, id from ranktest;
select RANK() over (ORDER BY id) as foo, id from ranktest;

select RANK() over () as foo, id, k from ranktest;
select RANK() over (PARTITION BY id) as foo, id, k from ranktest;
select RANK() over (PARTITION BY id ORDER BY id, k) as foo, id, k from ranktest;
select RANK() over (ORDER BY id, k) as foo, id, k from ranktest;

select DENSE_RANK() over () as foo, id, k from ranktest order by k;
select DENSE_RANK() over (PARTITION BY id) as foo, id, k from ranktest order by k;
select DENSE_RANK() over (PARTITION BY id ORDER BY id, k) as foo, id, k from ranktest order by k;
select DENSE_RANK() over (ORDER BY id, k) as foo, id, k from ranktest order by k;
drop table ranktest;

For more examples see extended_sql_window_functions

The SQL implementation provides the well-known standard statistical aggregates COUNT, SUM, AVG, MIN and MAX over scalar types and groupings. In addition, a few important statistical aggregate functions: MEDIAN, QUANTILE, and correlation CORR are available. The percentile is a float value between 0.0 and 1.0. MEDIAN(<expr>) is equivalent to QUANTILE(<expr>,0.5). 

STDDEV_SAMP computes the cumulative sample standard deviation and returns the square root of the sample variance. STDDEV_POP computes the population standard deviation and returns the square root of the population variance. Both functions take takes as an argument any numeric datatype.
Likewise, VAR_SAMP and VAR_POP function returns the sample variance (/n-1) of a set of numbers and the biased variance (/n) of a set of numbers, respectively.

The COPY INTO command enables fast insertion of multiple tuples from an text file or standard input. Each tuple  in the input file is terminated by a record-separator (default '\n') and fields are separated by the field separator (default '|'). The field values should adhere to the  syntax for value literals. Alternative separators should adhere to the SQL lexical syntax for string values. A different NULL value representation can be passed using the NULL as null_string option. Furthermore, the fields are optionally enclosed with a user defined quote character. The text file should use UTF-8 encoding if specified as file_name, and the same encoding as mclient is using if read using FROM STDIN.

It is strongly advised to announce the maximum number of records to be inserted. It avoids guessing by the server and subsequent re-allocation of table space which may involve potentially expensive copying. A portion of the input file can be skipped using the offset feature.  The offset value specifies the record at which loading should commence, the first record having offset 1.

As of the Aug2018-SP2 release, if using FROM STDIN and the number of records is not specified, reading the input stops at an empty line. This means that if a one column table is being read, there may be confusion as to whether an empty line is an empty (string) value or a NULL (if NULL AS '' is specified). The end of input takes precedence here.

As of the Apr2019 release (11.33.3), the option ON CLIENT or ON SERVER can be used. This allows the client to read/write files from/to the client instead of doing it in the server. This has the advantage that COPY INTO is then no longer restricted to only the "super user" monetdb, nor only to absolute file names. The syntax to have the server communicate with the client for file content is COPY INTO table FROM file ON CLIENT ...; and COPY query INTO file ON CLIENT ...;. This also works for COPY BINARY INTO. There is also the possibility to specify that files are to be read/written by the server by using ON SERVER. This is also the default when ON CLIENT or ON SERVER is not specified. In that case the file must be accessible by the server. Therefore, it must reside on or be accessible to the database server machine and they must be identified with an absolute path name.

The STDIN file designator reads data streaming from the client application. An empty record determines the end of sequence.

The input syntax should comply to the following grammar: [ [ [quote] [[escape]char] * [quote]] feldspar] * record separator. Quote characters in quoted fields may be escaped with a backslash. Field and record separators can be embedded in quoted fields.

LOCKED mode

In many bulk loading situations, the original file can be saved as a backup or recreated for disaster handling. This reliefs the database system from having to prepare for recovery as well and to safe significant storage space. The LOCKED qualifier can be used in this situation (and in single user mode!) to skip the logging operation normally performed.

WARNING It is advised to add integrity constraints to the table after the file has been loaded. The ALTER statements perform bulk integrity checking and perform these checks often more efficiently.

For more see the CSV bulk load recipe.

Copy into File

The COPY INTO command with a file name argument allows for fast dumping of a result set into an ASCII file. The file must be accessible by the server and a full path name may be required. The file STDOUT can be used to direct the result to the primary output channel.

The delimiters and NULL AS arguments provide control over the layout required.  

For both the input and output versions of the COPY INTO commands one can specify a file name ending with '.gz' or '.bz2' or '.xz' or '.lz4' to use the appropriate compression library (if available).

For more see the Exporting bulk data recipe.

Copying binary files

Migration of tables between MonetDB/SQL instances can be speed up using the COPY BINARY INTO format.

For more see the Binary bulk data load recipe.

In the Aug2018 release of MonetDB, we added a new aggregation function "sys.group_concat", which aggregates an input column into a single string as output. We provide two versions of this aggregate: sys.group_concat(string) and sys.group_concat(string, string). In both versions, the first parameter corresponds to the input string column to be concatenated. In the former the default delimiter is the ',' character, in the latter the second parameter indicates the separator to be used. If either a group in has a NULL value, or the delimiter is NULL, the output will be NULL.

sql>create table demo (a int, b clob);
operation successful
sql>insert into demo values (1, 'chair'), (1, 'desk'), (2, 'room'), (1, 'decoration'), (2, 'window'), (2, 'sofa');
6 affected rows
sql>select '[' || sys.group_concat(a) || ']' from demo;
+---------------+
| L3            |
+===============+
| [1,1,2,1,2,2] |
+---------------+
1 tuple
sql>select a, sys.group_concat(b) from demo group by a;
+------+-----------------------+
| a    | L4                    |
+======+=======================+
| 1    | chair,desk,decoration |
| 2    | room,window,sofa      |
+------+-----------------------+
2 tuples
sql>select a, sys.group_concat(b, '|') from demo group by a;
+------+-----------------------+
| a    | L5                    |
+======+=======================+
|    1 | chair|desk|decoration |
|    2 | room|window|sofa      |
+------+-----------------------+
2 tuples
sql>insert into demo values (3, 'car'), (3, NULL);
2 affected rows
sql>select '[' || sys.group_concat(b, '-') || ']' from demo group by a;
+-------------------------+
| L6                      |
+=========================+
| [chair-desk-decoration] |
| [room-window-sofa]      |
| null                    |
+-------------------------+
3 tuples

Note: CREATE ... EXTERNAL NAME ... is a MonetDB language extension.

The SQL standard allows to create SQL functions. MonetDB supports this feature. The syntax to create a function is:

External functions provide a convenient bridge between SQL and MAL. This way also a bridge can be established with dynamically loaded functions written in C. Any SQL function signature can be bound to MAL function or command.

The example below illustrates a binding to the a function that produces a tabular overview of the BAT catalog.

CREATE FUNCTION bbp ()
RETURNS TABLE (id int, name string, htype string,
    string, count BIGINT, refcnt int, lrefcnt int,
    location string, heat int, dirty string, status string,
    kind string)
EXTERNAL NAME sql.bbp;

A table returning function should be implemented as MAL function that returns a series of synchronized BATs.

FUNCTION bbp():bat[:str,:bat];
   b := bat.new(:str,:bat,12);
   ns := bbp.getNames();
   ri := algebra.markT(ns, 0:oid);
   ...
   kind := algebra.markH(ikind, 0:oid);
   bat.insert(b, "kind", kind);
   RETURN b;
END bbp;

Two useful Microsoft functions supported are 'STUFF' and 'ROUND'. 

SQL> SELECT MS_ROUND(10.0, 1, 0);

The SQL definition for MS_ROUND is:

CREATE OR REPLACE FUNCTION MS_ROUND(num float, precision int, truncat int)
RETURNS float
BEGIN
   IF (truncat = 0)
   THEN RETURN ROUND(num, precision);
   ELSE RETURN TRUNCATE(num, precision);
   END IF;
END;

The SQL definition for MS_STUFF is:

CREATE FUNCTION MS_STUFF( s1 varchar(32), st int, len int, s3 varchar(32))
RETURNS varchar(32)
BEGIN
   DECLARE res varchar(32), aux varchar(32);
   DECLARE ofset int;
   SET ofset = 0;
   SET res = SUBSTRING(s1,ofset,st-1);
   SET res = res || s3;
   SET ofset = LENGTH(s1)-len;
   SET aux = SUBSTRING(s1,ofset, len);
   SET res = res || aux;
   RETURN res;
END;

Note: CREATE FILTER FUNCTION is a MonetDB language extension. The SQL standard does not provide for user-defined filter functions such as my_like ... .

Note: CREATE AGGREGATE is a MonetDB language extension. The SQL standard does not provide for user-defined aggregate functions.

Note: CREATE ... EXTERNAL ... and CREATE ... LANGUAGE ... are MonetDB language extensions.

Triggers are a convenient programming abstraction. They are activated at transaction commit based on updates to the base tables.

Example The following example provides a glimpse of their functionality:

create table t1 (id int, name varchar(1024));
--test FOR EACH STATEMENT (default one)
insert into t1 values(10, 'monetdb');
insert into t1 values(20, 'monet');
create trigger test5
after update on t1
for each statement
when id >0 insert into t1 values(4, 'update_when_statement_true');

All trigger definitions are considered together at the transaction commit. There is no a priori defined order in which they run. Each may in turn activate new triggers, but each trigger definition is also executed only once per transaction commit.

MonetDB/SQL supports session variables declared by the user. They are indistinguishable from table and column names and can be used anywhere a literal constant is allowed.

Examples

sql>DECLARE high integer;
sql>DECLARE n varchar(256);
sql>SET high=4000;
sql>SET n='monetdb'
sql>SET trace = 'ticks,stmt'
sql>SELECT count(*) from tables where id > high;
+--------+
| count_ |
+========+
| 2      |
+--------+

The SQL variables (and environment variables) can be accessed through predefined table returning functions var() and env(). The debug variable settings are defined in the MonetDB config file. The current_* variables are SQL environment settings. The trace variables is defined in the TRACE command.

sql>select * from var();
+------------------+
| name             |
+==================+
| debug            |
| cache            |
| current_schema   |
| current_user     |
| current_role     |
| optimizer        |
| current_timezone |
| last_id          |
| rowcnte            |
+------------------+

The persistent stored module facility of SQL provides a method to encode complex algorithm using well-known programming features.

The intermediate mal code produced by the SQL compiler can be made visible using the explain statement modifier. It gives a detailed description of the actions taken to produce the answer. The example below illustrates what you can expect when a simple "select count(*) from tables" query starts with the explain modifier. The output strongly depends on the optimizer pipeline. The details of this program are better understood when you have read the MAL reference.

sql>select count(*) from tables;
+------+
| L41  |
+======+
|   93 |
+------+
1 tuple
clk: 1.993ms
sql>explain select count(*) from tables;
+--------------------------------------------------------------------------------------------------------------------+
| mal                                                                                                                |
+====================================================================================================================+
| function user.s6_2():void;                                                                                         |
|     X_1:void := querylog.define("explain select count(*) from tables;":str, "default_pipe":str, 30:int);           |
| barrier X_106:bit := language.dataflow();                                                                          |
|     X_38:bat[:lng] := bat.new(nil:lng);                                                                            |
|     X_4:int := sql.mvc();                                                                                          |
|     X_18:bat[:sht] := sql.bind(X_4:int, "sys":str, "_tables":str, "type":str, 0:int);                              |
|     C_5:bat[:oid] := sql.tid(X_4:int, "sys":str, "_tables":str);                                                   |
|     C_91:bat[:oid] := algebra.thetaselect(X_18:bat[:sht], C_5:bat[:oid], 2:sht, "!=":str);                         |
|     (X_21:bat[:oid], X_22:bat[:sht]) := sql.bind(X_4:int, "sys":str, "_tables":str, "type":str, 2:int);            |
|     C_92:bat[:oid] := algebra.thetaselect(X_22:bat[:sht], nil:bat[:oid], 2:sht, "!=":str);                         |
|     X_20:bat[:sht] := sql.bind(X_4:int, "sys":str, "_tables":str, "type":str, 1:int);                              |
|     C_94:bat[:oid] := algebra.thetaselect(X_20:bat[:sht], C_5:bat[:oid], 2:sht, "!=":str);                         |
|     C_27:bat[:oid] := sql.subdelta(C_91:bat[:oid], C_5:bat[:oid], X_21:bat[:oid], C_92:bat[:oid], C_94:bat[:oid]); |
|     X_31:lng := aggr.count(C_27:bat[:oid]);                                                                        |
|     X_37:bat[:lng] := sql.single(X_31:lng);                                                                        |
|     C_32:bat[:oid] := sql.tid(X_4:int, "tmp":str, "_tables":str);                                                  |
|     X_36:lng := aggr.count(C_32:bat[:oid]);                                                                        |
|     X_40:bat[:lng] := bat.append(X_38:bat[:lng], X_37:bat[:lng], true:bit);                                        |
|     X_42:bat[:lng] := bat.append(X_40:bat[:lng], X_36:lng, true:bit);                                              |
|     X_43:lng := aggr.sum(X_42:bat[:lng]);                                                                          |
|     language.pass(C_5:bat[:oid]);                                                                                  |
| exit X_106:bit;                                                                                                    |
|     sql.resultSet(".L41":str, "L41":str, "bigint":str, 64:int, 0:int, 7:int, X_43:lng);                            |
| end user.s6_2;                                                                                                     |
...
+--------------------------------------------------------------------------------------------------------------------+
50 tuples
clk: 3.942 ms

The SQL compiler maintains a cache of compiled (or prepared) queries. Each query is looked up in this cache based on an expression pattern match where the constants may take on different values. If it doesn't exist, the query is converted into a code block and stored in the module user.s0.

The call to the cached function is included in a wrapper function main, which is the only piece of code produced if the query is used more than once. The query cache disappears when the server is brought to a halt.

     +----------------------------+
     | function user.main():void; |
     |     mdb.start();           |
     |     user.s3_2();           |
     |     mdb.stop();            |
     | end main;                  |
     +----------------------------+

A performance trace can be obtained using the TRACE statement modifier. It collects  trace information in a table accessed by sys.tracelog(), which can be queried using ordinary SQL statements. This internal temporary table is reset each new query being traced. Its definition is given below:

CREATE FUNCTION sys.tracelog()
    RETURNS table (
        ticks bigint,       -- time in microseconds
        stmt string         -- actual MAL statement executed
    )
   EXTERNAL NAME sql.dump_trace;

CREATE VIEW sys.tracelog AS SELECT * FROM sys.tracelog();

For more detailed performance analysis consider using the Stethoscpe.

The SQL statements are translated into MAL programs, which are optimized and stored away in an user module. The generated code can be inspected with the MAL debugger.

The example below illustrates the start of such a session:

>debug select count(*) from tables;
#    mdb.start()
mdb>next
#    user.s1_0()
mdb>next
#    _2:bat[:oid,:int]  := sql.bind(_3="sys", _4="ptables", _5="id", _6=0)
mdb>next
#    _8:bat[:oid,:int]  := sql.bind(_3="sys", _4="ptables", _5="id", _9=1)
mdb> ...
mdb>help
next             -- Advance to next statement
continue         -- Continue program being debugged
catch            -- Catch the next exception 
break [<var>]    -- set breakpoint on current instruction or <var>
delete [<var>]   -- remove break/trace point <var>
debug <int>      -- set kernel debugging mask
dot <obj> [<file>]     -- generate the dependency graph for MAL block
step             -- advance to next MAL instruction
module           -- display the module signatures
atom             -- show atom list
finish           -- finish current call
exit             -- terminate execution
quit             -- turn off debugging
list <obj>       -- list a MAL program block
list #  [+#],-#  -- list current program block slice
List <obj> [#]   -- list MAL block with type information[slice]
list '['<step>']'  -- list program block after optimizer step
List #[+#],-#    -- list current program block slice
var  <obj>       -- print symbol table for module
optimizer <obj>  -- display optimizer steps
print <var>      -- display value of a variable
print <var> <cnt>[<first>]   -- display BAT chunk
info <var>       -- display bat variable properties
run              -- restart current procedure
where            -- print stack trace
down             -- go down the stack
up               -- go up the stack
trace <var>      -- trace assignment to variables
help             -- this message

The relational plan used in the SQL optimizer can be obtained by prepending the query with the keyword PLAN.

sql>plan select count(*) from tables;
+----------------------------------------------------------------------------+
| rel                                                                        |
+============================================================================+
| project (                                                                  |
| | group by (                                                               |
| | | union (                                                                |
| | | | group by (                                                           |
| | | | | project (                                                          |
| | | | | | select (                                                         |
| | | | | | | table(sys._tables) [ "_tables"."id", "_tables"."type" ] COUNT  |
| | | | | | ) [ "_tables"."type" != smallint "2" ]                           |
| | | | | ) [ "_tables"."id" as "tables"."id" ]                              |
| | | | ) [  ] [ sys.count() NOT NULL as "L41"."L41" ],                      |
| | | | group by (                                                           |
| | | | | project (                                                          |
| | | | | | table(tmp._tables) [ "_tables"."id" ] COUNT                      |
| | | | | ) [ "_tables"."id" as "tables"."id" ]                              |
| | | | ) [  ] [ sys.count() NOT NULL as "L41"."L41" ]                       |
| | | ) [ "L41"."L41" ]                                                      |
| | ) [  ] [ sys.sum no nil ("L41"."L41") as "L41"."L41" ]                   |
| ) [ "L41"."L41" NOT NULL ]                                                 |
+----------------------------------------------------------------------------+
18 tuples
clk: 1.158 ms

The PREPARE statement compiles an SQL statement into its execution plan on the server. The plan is given a name and stored in the query cache. A subsequent EXECUTE command retrieves it from the cache, applies the given parameter values and executes it.

PREPARE statement executions can be given positional arguments to replace any literal constant in the query.  Each argument is denoted with a '?'.

sql>prepare select * from tables where name = ?;
execute prepared statement using: EXEC 5(...)
clk: 4.123 ms
+----------+---------+-------+--------+--------+---------------+
| type     | digits  | scale | schema | table  | column        |
+==========+=========+=======+========+========+===============+
| int      |      32 |     0 |        | tables | id            |
| varchar  |    1024 |     0 |        | tables | name          |
| int      |      32 |     0 |        | tables | schema_id     |
| varchar  | 1048576 |     0 |        | tables | query         |
| smallint |      16 |     0 |        | tables | type          |
| boolean  |       1 |     0 |        | tables | system        |
| smallint |      16 |     0 |        | tables | commit_action |
| smallint |      16 |     0 |        | tables | access        |
| tinyint  |       8 |     0 |        | tables | temporary     |
| varchar  |    1024 |     0 | null   | null   | null          |
+----------+---------+-------+--------+--------+---------------+
10 tuples
clk: 4.123 ms

sql>execute 5('_tables');
+------+---------+-----------+-------+------+--------+---------------+--------+-----------+
| id   | name    | schema_id | query | type | system | commit_action | access | temporary |
+======+=========+===========+=======+======+========+===============+========+===========+
| 2067 | _tables |      2000 | null  |   10 | true   |             0 |      0 |         0 |
| 2115 | _tables |      2114 | null  |   10 | true   |             2 |      0 |         0 |
+------+---------+-----------+-------+------+--------+---------------+--------+-----------+
2 tuples
clk: 2.692 ms

sql>exec 5('table_types');
+------+-------------+-----------+-------+------+--------+---------------+--------+-----------+
| id   | name        | schema_id | query | type | system | commit_action | access | temporary |
+======+=============+===========+=======+======+========+===============+========+===========+
| 7322 | table_types |      2000 | null  |   10 | true   |             0 |      1 |         0 |
+------+-------------+-----------+-------+------+--------+---------------+--------+-----------+
1 tuple
clk: 2.364 ms

The Mapi Library

The easiest way to extend the functionality of MonetDB is to construct an independent application, which communicates with a running server using a database driver with a simple API and a textual protocol. The effectiveness of such an approach has been demonstrated by the wide use of database API implementations, such as Perl DBI, PHP, ODBC,...

Sample MAPI Application

The database driver implementation given in this document focuses on developing applications in C. The command collection has been chosen to align with common practice, i.e. queries follow a prepare, execute, and fetch_row paradigm. The output is considered a regular table. An example of a mini application below illustrates the main operations.

#include <mapi.h> 
#include <stdio.h> 
#include <stdlib.h> 

void die(Mapi dbh, MapiHdl hdl) { 
  if (hdl != NULL) { 
    mapi_explain_query(hdl, stderr); 
    do { 
      if (mapi_result_error(hdl) != NULL) 
        mapi_explain_result(hdl, stderr); 
    } while (mapi_next_result(hdl) == 1); 
    mapi_close_handle(hdl); 
    mapi_destroy(dbh); 
  } else if (dbh != NULL) { 
    mapi_explain(dbh, stderr); 
    mapi_destroy(dbh); 
  } else { 
    fprintf(stderr, "command failed\n"); 
  } 
  exit(-1); 
} 

MapiHdl query(Mapi dbh, char *q) { 
  MapiHdl ret = NULL; 

  if ((ret = mapi_query(dbh, q)) == NULL || mapi_error(dbh) != MOK) 
    die(dbh, ret); 

  return(ret); 
} 

void update(Mapi dbh, char *q) { 
  MapiHdl ret = query(dbh, q); 

  if (mapi_close_handle(ret) != MOK) 
    die(dbh, ret); 
} 

int main(int argc, char *argv[]) { 
  Mapi dbh; 
  MapiHdl hdl = NULL; 
  char *name; 
  char *age; 
  dbh = mapi_connect("localhost", 50000, "monetdb", "monetdb", "sql", "demo"); 

  if (mapi_error(dbh)) 
    die(dbh, hdl); 

  update(dbh, "CREATE TABLE emp (name VARCHAR(20), age INT)"); 
  update(dbh, "INSERT INTO emp VALUES ('John', 23)"); 
  update(dbh, "INSERT INTO emp VALUES ('Mary', 22)"); 
  hdl = query(dbh, "SELECT * FROM emp"); 

  while (mapi_fetch_row(hdl)) { 
    name = mapi_fetch_field(hdl, 0); 
    age = mapi_fetch_field(hdl, 1); 
    printf("%s is %s\n", name, age); 
  } 

  mapi_close_handle(hdl); 
  mapi_destroy(dbh); 
  return(0); 
} 

The mapi_connect() operation establishes a communication channel with a running server. The query language interface is either "sql" or "mal".

Errors on the interaction can be captured using mapi_error(), possibly followed by a request to dump a short error message explanation on a standard file location. It has been abstracted away in a function.

Provided we can establish a connection, the interaction proceeds as in many similar application development packages. Queries are shipped for execution using mapi_query() and an answer table can be consumed one row at a time. In many cases these functions suffice.

The Mapi interface provides caching of rows at the client side. mapi_query() will load tuples into the cache, after which they can be read repeatedly using mapi_fetch_row() or directly accessed (mapi_seek_row()). This facility is particularly handy when small, but stable query results are repeatedly used in the client program.

To ease communication between application code and the cache entries, the user can bind the C-variables both for input and output to the query parameters, and output columns, respectively. The query parameters are indicated by '?' and may appear anywhere in the query template.

The Mapi library expects complete lines from the server as answers to query actions. Incomplete lines leads to Mapi waiting forever on the server. Thus formatted printing is discouraged in favor of tabular printing as offered by the table.print() commands.

The following action is needed to get a working program. Compilation of the application relies on libtool and the pkg-config programs that should be shipped with your installation.  The application above can be compiled and linked as follows:

% libtool --mode=compile --tag=CC gcc -c `env PKG_CONFIG_PATH=$INSTALL_DIR/lib/pkgconfig pkg-config --cflags monetdb-mapi` test.c % libtool --mode=link --tag=CC gcc -o test `env PKG_CONFIG_PATH=$INSTALL_DIR/lib/pkgconfig pkg-config --libs monetdb-mapi` test.o % ./test 

The example assumes you have set the variable INSTALL_DIR to the prefix location given during configure of MonetDB.  If you use a system installation, you can omit the 'env PKGCONFIG_PATH=.....' part, or set INSTALL_DIR to '/usr'.

The compilation on Windows is slightly more complicated. It requires more attention towards the location of the include files and libraries.

Command Summary

The quick reference guide to the Mapi library is given below. More details on their constraints and defaults are given in the next section.

Library Synopsis

The routines to build a MonetDB application are grouped in the library MonetDB Programming Interface, or shorthand Mapi.

The protocol information is stored in a Mapi interface descriptor (mid). This descriptor can be used to ship queries, which return a MapiHdl to represent the query answer. The application can set up several channels with the same or a different mserver. It is the programmer's responsibility not to mix the descriptors in retrieving the results.

The application may be multi-threaded as long as the user respects the individual connections represented by the database handlers.

The interface assumes a cautious user, who understands and has experience with the query or programming language model. It should also be clear that references returned by the API point directly into the administrative structures of Mapi. This means that they are valid only for a short period, mostly between successive mapi_fetch_row() commands. It also means that it the values are to retained, they have to be copied. A defensive programming style is advised.

Upon an error, the routines mapi_explain() and mapi_explain_query() give information about the context of the failed call, including the expression shipped and any response received. The side-effect is clearing the error status.

Error Message

Almost every call can fail since the connection with the database server can fail at any time. Functions that return a handle (either Mapi or MapiHdl) may return NULL on failure, or they may return the handle with the error flag set. If the function returns a non-NULL handle, always check for errors with mapi_error.

Functions that return MapiMsg indicate success and failure with the following codes.

When these functions return MERROR or MTIMEOUT, an explanation of the error can be had by calling one of the functions mapi_error_str(), mapi_explain(), or mapi_explain_query().

To check for error messages from the server, call mapi_result_error(). This function returns NULL if there was no error, or the error message if there was. A user-friendly message can be printed using map_explain_result(). Typical usage is:

do {
    if ((error = mapi_result_error(hdl)) != NULL)
        mapi_explain_result(hdl, stderr);
    while ((line = mapi_fetch_line(hdl)) != NULL)
        /* use output */;
} while (mapi_next_result(hdl) == 1);

Mapi Function Reference

Connecting and Disconnecting

• Mapi mapi_connect(const char *host, int port, const char *username, const char *password, const char *lang, const char *dbname)

  Setup a connection with a Mserver at a host:port and login with username and password. If host == NULL, the local host is accessed. If host starts with a '/' and the system supports it, host is actually the name of a UNIX domain socket, and port is ignored. If port == 0, a default port is used. If username == NULL, the username of the owner of the client application containing the Mapi code is used. If password == NULL, the password is omitted. The preferred query language is any of {sql,mil,mal,xquery }. On success, the function returns a pointer to a structure with administration about the connection.

• MapiMsg mapi_disconnect(Mapi mid)

  Terminate the session described by mid. The only possible uses of the handle after this call is mapi_destroy() and mapi_reconnect(). Other uses lead to failure.

• MapiMsg mapi_destroy(Mapi mid)

  Terminate the session described by mid if not already done so, and free all resources. The handle cannot be used anymore.

• MapiMsg mapi_reconnect(Mapi mid)

  Close the current channel (if still open) and re-establish a fresh connection. This will remove all global session variables.

• MapiMsg mapi_ping(Mapi mid)

  Test availability of the server. Returns zero upon success.

Sending Queries

• MapiHdl mapi_query(Mapi mid, const char *Command)

  Send the Command to the database server represented by mid. This function returns a query handle with which the results of the query can be retrieved. The handle should be closed with mapi_close_handle(). The command response is buffered for consumption, c.f. mapi_fetch_row().

• MapiMsg mapi_query_handle(MapiHdl hdl, const char *Command)

  Send the Command to the database server represented by hdl, reusing the handle from a previous query. If Command is zero it takes the last query string kept around. The command response is buffered for consumption, e.g. mapi_fetch_row().

• MapiHdl mapi_query_array(Mapi mid, const char *Command, char **argv)

  Send the Command to the database server replacing the placeholders (?) by the string arguments presented.

• MapiHdl mapi_quick_query(Mapi mid, const char *Command, FILE *fd)

  Similar to mapi_query(), except that the response of the server is copied immediately to the file indicated.

• MapiHdl mapi_quick_query_array(Mapi mid, const char *Command, char **argv, FILE *fd)

  Similar to mapi_query_array(), except that the response of the server is not analyzed, but shipped immediately to the file indicated.

• MapiHdl mapi_stream_query(Mapi mid, const char *Command, int windowsize)

  Send the request for processing and fetch a limited number of tuples (determined by the window size) to assess any erroneous situation. Thereafter, prepare for continual reading of tuples from the stream, until an error occurs. Each time a tuple arrives, the cache is shifted one.

• MapiHdl mapi_prepare(Mapi mid, const char *Command)

  Move the query to a newly allocated query handle (which is returned). Possibly interact with the back-end to prepare the query for execution.

• MapiMsg mapi_execute(MapiHdl hdl)

  Ship a previously prepared command to the backend for execution. A single answer is pre-fetched to detect any runtime error. MOK is returned upon success.

• MapiMsg mapi_execute_array(MapiHdl hdl, char **argv)

  Similar to mapi_execute but replacing the placeholders for the string values provided.

• MapiMsg mapi_finish(MapiHdl hdl)

  Terminate a query. This routine is used in the rare cases that consumption of the tuple stream produced should be prematurely terminated. It is automatically called when a new query using the same query handle is shipped to the database and when the query handle is closed with mapi_close_handle().

• MapiMsg mapi_virtual_result(MapiHdl hdl, int columns, const char **columnnames, const char **columntypes, const int *columnlengths, int tuplecount, const char ***tuples)

  Submit a table of results to the library that can then subsequently be accessed as if it came from the server. columns is the number of columns of the result set and must be greater than zero. columnnames is a list of pointers to strings giving the names of the individual columns. Each pointer may be NULL and columnnames may be NULL if there are no names. tuplecount is the length (number of rows) of the result set. If tuplecount is less than zero, the number of rows is determined by a NULL pointer in the list of tuples pointers. tuples is a list of pointers to row values. Each row value is a list of pointers to strings giving the individual results. If one of these pointers is NULL it indicates a NULL/nil value.

Getting Results

• int mapi_get_field_count(MapiHdl mid)

  Return the number of fields in the current row.

• mapi_int64 mapi_get_row_count(MapiHdl mid)

  If possible, return the number of rows in the last select call. A -1 is returned if this information is not available.

• mapi_int64 mapi_get_last_id(MapiHdl mid)

  If possible, return the last inserted id of auto_increment (or alike) column. A -1 is returned if this information is not available. We restrict this to single row inserts and one auto_increment column per table. If the restrictions do not hold, the result is unspecified.

• mapi_int64 mapi_rows_affected(MapiHdl hdl)

  Return the number of rows affected by a database update command such as SQL's INSERT/DELETE/UPDATE statements.

• int mapi_fetch_row(MapiHdl hdl)

  Retrieve a row from the server. The text retrieved is kept around in a buffer linked with the query handle from which selective fields can be extracted. It returns the number of fields recognized. A zero is returned upon encountering end of sequence or error. This can be analyzed in using mapi_error().

• mapi_int64 mapi_fetch_all_rows(MapiHdl hdl)

  All rows are cached at the client side first. Subsequent calls to mapi_fetch_row() will take the row from the cache. The number or rows cached is returned.

• int mapi_quick_response(MapiHdl hdl, FILE *fd)

  Read the answer to a query and pass the results verbatim to a stream. The result is not analyzed or cached.

• MapiMsg mapi_seek_row(MapiHdl hdl, mapi_int64 rownr, int whence)

  Reset the row pointer to the requested row number. If whence is MAPI_SEEK_SET, rownr is the absolute row number (0 being the first row); if whence is MAPI_SEEK_CUR, rownr is relative to the current row; if whence is MAPI_SEEK_END, rownr is relative to the last row.

• MapiMsg mapi_fetch_reset(MapiHdl hdl)

  Reset the row pointer to the first line in the cache. This need not be a tuple. This is mostly used in combination with fetching all tuples at once.

• char **mapi_fetch_field_array(MapiHdl hdl)

  Return an array of string pointers to the individual fields. A zero is returned upon encountering end of sequence or error. This can be analyzed in using mapi_error().

• char *mapi_fetch_field(MapiHdl hdl, int fnr)

  Return a pointer a C-string representation of the value returned. A zero is returned upon encountering an error or when the database value is NULL; this can be analyzed in using mapi_error().

• size_t mapi_fetch_fiels_len(MapiHdl hdl, int fnr)

  Return the length of the C-string representation excluding trailing NULL byte of the value. Zero is returned upon encountering an error, when the database value is NULL, of when the string is the empty string. This can be analyzed by using mapi_error() and mapi_fetch_field().

• MapiMsg mapi_next_result(MapiHdl hdl)

  Go to the next result set, discarding the rest of the output of the current result set.

Errors handling

• MapiMsg mapi_error(Mapi mid)

  Return the last error code or 0 if there is no error.

• char *mapi_error_str(Mapi mid)

  Return a pointer to the last error message.

• char *mapi_result_error(MapiHdl hdl)

  Return a pointer to the last error message from the server.

• MapiMsg mapi_explain(Mapi mid, FILE *fd)

  Write the error message obtained from mserver to a file.

• MapiMsg mapi_explain_query(MapiHdl hdl, FILE *fd)

  Write the error message obtained from mserver to a file.

• MapiMsg mapi_explain_result(MapiHdl hdl, FILE *fd)

  Write the error message obtained from mserver to a file.

Parameters

• MapiMsg mapi_bind(MapiHdl hdl, int fldnr, char **val)

  Bind a string variable with a field in the return table. Upon a successful subsequent mapi_fetch_row() the indicated field is stored in the space pointed to by val. Returns an error if the field identified does not exist.

• MapiMsg mapi_bind_var(MapiHdl hdl, int fldnr, int type, void *val)

  Bind a variable to a field in the return table. Upon a successful subsequent mapi_fetch_row(), the indicated field is converted to the given type and stored in the space pointed to by val. The types recognized are { MAPI_TINY, MAPI_UTINY, MAPI_SHORT, MAPI_USHORT, MAPI_INT, MAPI_UINT, MAPI_LONG, MAPI_ULONG, MAPI_LONGLONG, MAPI_ULONGLONG, MAPI_CHAR, MAPI_VARCHAR, MAPI_FLOAT, MAPI_DOUBLE, MAPI_DATE, MAPI_TIME, MAPI_DATETIME }. The binding operations should be performed after the mapi_execute command. Subsequently all rows being fetched also involve delivery of the field values in the C-variables using proper conversion. For variable length strings a pointer is set into the cache.

• MapiMsg mapi_bind_numeric(MapiHdl hdl, int fldnr, int scale, int precision, void *val)

  Bind to a numeric variable, internally represented by MAPI_INT Describe the location of a numeric parameter in a query template.

• MapiMsg mapi_clear_bindings(MapiHdl hdl)

  Clear all field bindings.

• MapiMsg mapi_param(MapiHdl hdl, int fldnr, char **val)

  Bind a string variable with the n-th placeholder in the query template. No conversion takes place.

• MapiMsg mapi_param_type(MapiHdl hdl, int fldnr, int ctype, int sqltype, void *val)

  Bind a variable whose type is described by ctype to a parameter whose type is described by sqltype.

• MapiMsg mapi_param_numeric(MapiHdl hdl, int fldnr, int scale, int precision, void *val)

  Bind to a numeric variable, internally represented by MAPI_INT.

• MapiMsg mapi_param_string(MapiHdl hdl, int fldnr, int sqltype, char *val, int *sizeptr)

  Bind a string variable, internally represented by MAPI_VARCHAR, to a parameter. The sizeptr parameter points to the length of the string pointed to by val. If sizeptr == NULL or *sizeptr == -1, the string is NULL-terminated.

• MapiMsg mapi_clear_params(MapiHdl hdl)

  Clear all parameter bindings.

Miscellaneous

• MapiMsg mapi_setAutocommit(Mapi mid, int autocommit)

  Set the autocommit flag (default is on). This only has effect when the language is SQL. In that case, the server commits after each statement sent to the server.  More information about autocommit and multi-statements transactions can be found here.

• MapiMsg mapi_setAlgebra(Mapi mid, int algebra)

  Tell the backend to use or stop using the algebra-based compiler.

• MapiMsg mapi_cache_limit(Mapi mid, int maxrows)

  A limited number of tuples are pre-fetched after each execute(). If maxrows is negative, all rows will be fetched before the application is permitted to continue. Once the cache is filled, a number of tuples are shuffled to make room for new ones, but taking into account non-read elements. Filling the cache quicker than reading leads to an error.

• MapiMsg mapi_cache_shuffle(MapiHdl hdl, int percentage)

  Make room in the cache by shuffling percentage tuples out of the cache. It is sometimes handy to do so, for example, when your application is stream-based and you process each tuple as it arrives and still need a limited look-back. This percentage can be set between 0 to 100. Making shuffle= 100% (default) leads to paging behavior, while shuffle==1 leads to a sliding window over a tuple stream with 1% refreshing.

• MapiMsg mapi_cache_freeup(MapiHdl hdl, int percentage)

  Forcefully shuffle the cache making room for new rows. It ignores the read counter, so rows may be lost.

• char * mapi_quote(const char *str, int size)

  Escape special characters such as \n, \t in str with backslashes. The returned value is a newly allocated string which should be freed by the caller.

• char * mapi_unquote(const char *name)

  The reverse action of mapi_quote(), turning the database representation into a C-representation. The storage space is dynamically created and should be freed after use.

• MapiMsg mapi_output(Mapi mid, char *output)

  Set the output format for results send by the server.

• MapiMsg mapi_stream_into(Mapi mid, char *docname, char *colname, FILE *fp)

  Stream a document into the server. The name of the document is specified in docname, the collection is optionally specified in colname (if NULL, it defaults to docname), and the content of the document comes from fp.

• MapiMsg mapi_profile(Mapi mid, int flag)

  Set the profile flag to time commands send to the server.

• MapiMsg mapi_trace(Mapi mid, int flag)

  Set the trace flag to monitor interaction of the client with the library. It is primarilly used for debugging Mapi applications.

• int mapi_get_trace(Mapi mid)

  Return the current value of the trace flag.

• MapiMsg mapi_log(Mapi mid, const char *fname)

  Log the interaction between the client and server for offline inspection. Beware that the log file overwrites any previous log. For detailed interaction trace with the Mapi library itself use mapi_trace().

The remaining operations are wrappers around the data structures maintained. Note that column properties are derived from the table output returned from the server.

• char *mapi_get_name(MapiHdl hdl, int fnr)
• char *mapi_get_type(MapiHdl hdl, int fnr)
• char *mapi_get_table(MapiHdl hdl, int fnr)
• int mapi_get_len(Mapi mid, int fnr)
• char *mapi_get_dbname(Mapi mid)
• char *mapi_get_host(Mapi mid)
• char *mapi_get_user(Mapi mid)
• char *mapi_get_lang(Mapi mid)
• char *mapi_get_motd(Mapi mid)

MonetDB JDBC Driver

The most obvious way to connect to a data source using the Java programming language is by making use of the JDBC API. MonetDB supplies a 100% pure Java JDBC driver (type 4) which allows to connect and work with a MonetDB database from a Java program.

This document gives a short description how to use the MonetDB JDBC driver in Java applications. Familiarity with the Java JDBC API is required to fully understand this document. Please note that you can find the complete JDBC API on Oracle's web site http://docs.oracle.com/javase/7/docs/technotes/guides/jdbc/index.html.

The latest release of the MonetDB JDBC driver has implemented most of the essential JDBC API classes and methods (only CallableStatement is not yet implemented). If you make extensive use of JDBC API and semantics and rely on its features, please report any missing functionality on our bugzilla.

In order to use the MonetDB JDBC driver in Java applications you need (of course) a running MonetDB/SQL server instance, preferably via monetdbd.

Getting the JDBC driver Jar

The easiest way to acquire the driver is to download it from our MonetDB Java Download Area. You will find a jar file called monetdb-jdbc-X.Y.jre7.jar where X and Y are major and minor version numbers. The other two listed jar files (jdbcclient.jre7.jar and monetdb-mcl-*.jre7.jar) are optional utility jars. jdbcclient.jre7.jar contains a java command line program similar (but not equal) to mclient, see below.

Compiling the driver (using ant, optional)

If you prefer to build the driver yourself, make sure you acquire the MonetDB Java repository, e.g. as part of the source downloads. The Java sources are built using Apache's Ant tool and a make file. Simply issuing the command ant distjdbc should be sufficient to build the driver jar-archive in the subdirectory jars. See the ant web site for more documentation on the ant build-tool: http://ant.apache.org/. The Java sources currently require at least a Java 7 compatible compiler.

Using the JDBC driver in your Java programs

To use the MonetDB JDBC driver, the monetdb-jdbc-X.Y.jre7.jar jar-archive has to be in the Java classpath. Make sure this is actually the case. Note: as of Jul2015 release (monetdb-jdbc-2.17.jar) the MonetDB JDBC Driver only works with Java 7 (or higher) JVMs.

Using the MonetDB JDBC driver in your Java program:

  // request a Connection to a MonetDB server running on 'localhost' (with default port 50000) for database demo for user and password monetdb
  Connection con = DriverManager.getConnection("jdbc:monetdb://localhost/demo", "monetdb", "monetdb");

The MonetDB JDBC Connection URL string passed to the "getConnection()"method is defined as

   jdbc:monetdb://<hostname>[:<portnr>]/<databasename>[?<property>=<value>[&<property>=<value>]]

where elements between "<" and ">" are required and elements between "[" and "]" are optional.

Following optional connection properties are allowed:

	so_timeout=<time in milliseconds>
	language=mal
	language=sql
	treat_blob_as_binary=true
	treat_clob_as_varchar=true
	hash=<sha512, sha384>
	user=<login name>
	password=<secret value>
	debug=true
	logfile=<name logfile>

A sample Java JDBC program

import java.sql.*;

/**
 * This example assumes there exist tables a and b filled with some data.
 * On these tables some queries are executed and the JDBC driver is tested
 * on it's accuracy and robustness against 'users'.
 *
 * @author Fabian Groffen
 */
public class MJDBCTest {
    public static void main(String[] args) throws Exception {
        Connection con = null;
        Statement st = null;
        ResultSet rs = null;

        try {
            String con_url = "jdbc:monetdb://localhost:50000/mydb?so_timeout=10000&treat_clob_as_varchar=true";
            // make a connection to the MonetDB server using JDBC URL starting with: jdbc:monetdb:// 
            con = DriverManager.getConnection(con_url, "monetdb", "monetdb");
            // make a statement object
            st = con.createStatement();
            // execute SQL query which returns a ResultSet object
            String qry = "SELECT a.var1, COUNT(b.id) as total FROM a, b WHERE a.var1 = b.id AND a.var1 = 'andb' GROUP BY a.var1 ORDER BY a.var1, total;"
            rs = st.executeQuery(qry);
            // get meta data and print column names with their type
            ResultSetMetaData md = rs.getMetaData();
            for (int i = 1; i <= md.getColumnCount(); i++) {
                System.out.print(md.getColumnName(i) + ":" + md.getColumnTypeName(i) + "\t");
            }
            System.out.println("");
            // now print the data: only the first 5 rows, while there probably are
            // a lot more. This shouldn't cause any problems afterwards since the
            // result should get properly discarded when we close it
            for (int i = 0; rs.next() && i < 5; i++) {
                for (int j = 1; j <= md.getColumnCount(); j++) {
                    System.out.print(rs.getString(j) + "\t");
                }
                System.out.println("");
            }
            // close (server) resource as soon as we are done processing resultset data
            rs.close();
            rs = null;

            // tell the driver to only return 5 rows for the next execution
            // it can optimize on this value, and will not fetch any more than 5 rows.
            st.setMaxRows(5);
            // we ask the database for 22 rows, while we set the JDBC driver to
            // 5 rows, this shouldn't be a problem at all...
            rs = st.executeQuery("select * from a limit 22");
            int var1_cnr = rs.findColumn("var1");
            int var2_cnr = rs.findColumn("var2");
            int var3_cnr = rs.findColumn("var3");
            int var4_cnr = rs.findColumn("var4");
            // read till the driver says there are no rows left
            for (int i = 0; rs.next(); i++) {
                System.out.println(
                    "[" + rs.getString(var1_cnr) + "]" +
                    "[" + rs.getString(var2_cnr) + "]" +
                    "[" + rs.getInt(var3_cnr) + "]" +
                    "[" + rs.getString(var4_cnr) + "]" );
            }
            // close (server) resource as soon as we are done processing resultset data
            rs.close();
            rs = null;

            // unset the row limit; 0 means as much as the database sends us
            st.setMaxRows(0);
            // we only ask 10 rows
            rs = st.executeQuery("select * from b limit 10;");
            int rowid_cnr = rs.findColumn("rowid");
            int id_cnr = rs.findColumn("id");
            var1_cnr = rs.findColumn("var1");
            var2_cnr = rs.findColumn("var2");
            var3_cnr = rs.findColumn("var3");
            var4_cnr = rs.findColumn("var4");
            // and simply print them
            while (rs.next()) {
                System.out.println(
                    rs.getInt(rowid_cnr) + ", " +
                    rs.getString(id_cnr) + ", " +
                    rs.getInt(var1_cnr) + ", " +
                    rs.getInt(var2_cnr) + ", " +
                    rs.getString(var3_cnr) + ", " +
                    rs.getString(var4_cnr) );
            }
            // close (server) resource as soon as we are done processing resultset data
            rs.close();
            rs = null;

            // perform a ResultSet-less query (with no trailing ; since that should
            // be possible as well and is JDBC standard)
            int updCount = st.executeUpdate("delete from a where var1 = 'zzzz'");
            System.out.println("executeUpdate() returned: " + updCount);
        } catch (SQLException se) {
            System.out.println(se.getMessage());
        } finally {
            // when done, close all (server) resources
            if (rs != null) rs.close();
            if (st != null) st.close();
            if (con != null) con.close();
        }
    }
}

Note: it is no longer required (or recommended) to include code line:

  Class.forName("nl.cwi.monetdb.jdbc.MonetDriver");

as the MonetDriver class registers itself with the JDBC DriverManager automatically when the monetdb-jdbc-X.Y.jre7.jar file is loaded.

Using the JdbcClient utility program

We have created an example Java SQL command line program similar to (but not compatible with) mclient program. The jdbcclient.jre7.jar program can be downloaded from the MonetDB Java Download Area. It includes and uses the MonetDB JDBC driver internally. As it already includes the JDBC driver classes it is very easy to start it (assuming you have an MonetDB/SQL server running) via:

% java -jar jdbcclient.jre7.jar -p50000 -ddemo -umonetdb
password:

Welcome to the MonetDB interactive JDBC terminal!
Database Server: MonetDB v11.33.11
JDBC Driver: MonetDB Native Driver v2.29 (Liberica 20190926 based on MCL v1.18)
Current Schema: sys
Type \q to quit, \h for a list of available commands
auto commit mode: on
sql>

From this sql> prompt you can enter an SQL query (include an ; as end-of-statement) and execute it by using the enter-key.

If the connection fails, observe the error messages from JdbcClient (and/or the merovingian logs) for clues.

Use \q to quit the program.

To see all jdbcclient startup options just run:

% java -jar jdbcclient.jre7.jar --help

Tip: if you do not want to enter the password each time, use a .monetdb file (which contains the user and password settings) similar as for mclient

MonetDB ODBC Driver

Short for Open DataBase Connectivity, a standard database access method developed by the SQL Access group in 1992. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant – that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them.

The ODBC driver for MonetDB is included in the Windows installer and Linux RPMs. The source can be found in the SQL CVS tree.

To help you setup your system to use the ODBC driver with MonetDB, two how-tos are available, one for Windows users and one for Linux/UNIX users.

Microsoft Excel demo

A little demo showing how to import data from a MonetDB server into Microsoft Excel.

Using Excel with the MonetDB ODBC Driver

Start up the MonetDB SQL Server and Excel.

In Excel, select from the drop down menu, first Data, then Get External Data, and finally New Database Query...

If MonetDB was installed correctly, there should be an entry MonetDB in the dialog box that opens. Select it and click on OK.

In the wizard that opens, scroll down in the list on the left hand side and select voyages. Then click on the button labeled > and then on Next >.

In the next page of the wizard, click on Next >.

In the next page of the wizard, click on Next >.

In the final page of the wizard, click on Finish.

A new dialog window opens. Click on OK to insert the data into the current Excel worksheet.

That's all.

Installing the MonetDB ODBC Driver for unixODBC

Configuring the MonetDB Driver

As Superuser, start the unixODBC configuration program ODBCConfig and select the Drivers tab.

On this tab, click on the button labeled Add... and fill in the fields as follows.

Name

MonetDB

Description

ODBC Driver for MonetDB SQL Server

Driver

<path-to-MonetDB>/lib(64)/libMonetODBC.so

Setup

<path-to-MonetDB>/lib(64)/libMonetODBCs.so

Don't change the other fields. When done, click on the check mark in the top left corner of the window. The first window should now contain an entry for MonetDB. Click on OK

Configuring a Data Source

Now as normal user start ODBCConfig again.

On the User DSN tab click on the Add... button. A new window pops up in which you have to select the ODBC driver. Click on the entry for MonetDB and click on OK.

A new window pops up. Fill in the fields as follows.

Name

MonetDB

Description

Default MonetDB Data Source

Host

localhost

Port

50000

User

monetdb

Password

monetdb

Don't change the other fields. When done, click on the check mark in the top left corner of the window. The first window should now contain an entry for MonetDB. Click on OK

The MonetDB MAPI and SQL client python API

Introduction

This is the native python client API. This API is cross-platform, and doesn't depend on any monetdb libraries. It has support for python 2.7 and 3.3+ and is Python DBAPI 2.0 compatible.

Installation

To install the MonetDB python API run the following command:

# pip install pymonetdb

That's all, now you are ready to start using the API. We recommend that you use virtual environments to avoid polluting your global python installation.

Documentation

The python code is well documented, so if you need to find documentation you should have a look at the source code. Below is an interactive example on how to use the monetdb SQL API which should get you started quite fast.

Examples

There are some examples in the 'examples' folder, but here are is a line by line example of the SQL API:

> # import the SQL module
> import pymonetdb
>
> # set up a connection. arguments below are the defaults
> connection = pymonetdb.connect(username="monetdb", password="monetdb", hostname="localhost", database="demo")
>
> # create a cursor
> cursor = connection.cursor()
>
> # increase the rows fetched to increase performance (optional)
> cursor.arraysize = 100
>
> # execute a query (return the number of rows to fetch)
> cursor.execute('SELECT * FROM tables')
26
>
> # fetch only one row
> cursor.fetchone()
(1062, 'schemas', 1061, None, 0, True, 0, 0)
>
> # fetch the remaining rows
> cursor.fetchall()
[(1067, 'types', 1061, None, 0, True, 0, 0),
 (1076, 'functions', 1061, None, 0, True, 0, 0),
 (1085, 'args', 1061, None, 0, True, 0, 0),
 (1093, 'sequences', 1061, None, 0, True, 0, 0),
 (1103, 'dependencies', 1061, None, 0, True, 0, 0),
 (1107, 'connections', 1061, None, 0, True, 0, 0),
 (1116, '_tables', 1061, None, 0, True, 0, 0),
 ...
 (4141, 'user_role', 1061, None, 0, True, 0, 0),
 (4144, 'auths', 1061, None, 0, True, 0, 0),
 (4148, 'privileges', 1061, None, 0, True, 0, 0)]
>
> # Show the table meta data
> cursor.description
[('id', 'int', 4, 4, None, None, None),
 ('name', 'varchar', 12, 12, None, None, None),
 ('schema_id', 'int', 4, 4, None, None, None),
 ('query', 'varchar', 168, 168, None, None, None),
 ('type', 'smallint', 1, 1, None, None, None),
 ('system', 'boolean', 5, 5, None, None, None),
 ('commit_action', 'smallint', 1, 1, None, None, None),
 ('temporary', 'tinyint', 1, 1, None, None, None)]

If you would like to communicate with the database at a lower level you can use the MAPI library:

> from pymonetdb import mapi
> mapi_connection = mapi.Connection()
> mapi_connection.connect(hostname="localhost", port=50000, username="monetdb", password="monetdb", database="demo", language="sql", unix_socket=None, connect_timeout=-1)
> mapi_connection.cmd("sSELECT * FROM tables;")
...

MonetDB Perl Library

Perl is one of the more common scripting languages for which a 'standard' database application programming interface is defined. It is called DBI and it was designed to protect you from the API library details of multiple DBMS vendors. It has a very simple interface to execute SQL queries and for processing the results sent back. DBI doesn't know how to talk to any particular database, but it does know how to locate and load in DBD (`Database Driver') modules. The DBD modules encapsulate the interface library's intricacies and knows how to talk to the real databases.

MonetDB comes with its own DBD module which is included in both the source and binary distribution packages. The module is also available via CPAN.

Two sample Perl applications are included in the source distribution; a MIL session and a simple client to interact with a running server.

For further documentation we refer to the Perl community home page.

A Simple Perl Example

use strict;
use warnings;
use DBI();

print "\nStart a simple Monet MIL interaction\n\n";

# determine the data sources:
my @ds = DBI->data_sources('monetdb');
print "data sources: @ds\n";

# connect to the database:
my $dsn = 'dbi:monetdb:database=test;host=localhost;port=50000;language=mil';
my $dbh = DBI->connect( $dsn,
  undef, undef,  # no authentication in MIL
  { PrintError => 0, RaiseError => 1 }  # turn on exception handling
);
{
  # simple MIL statement:
  my $sth = $dbh->prepare('print(2);');
  $sth->execute;
  my @row = $sth->fetchrow_array;
  print "field[0]: $row[0], last index: $#row\n";
}
{
  my $sth = $dbh->prepare('print(3);');
  $sth->execute;
  my @row = $sth->fetchrow_array;
  print "field[0]: $row[0], last index: $#row\n";
}
{
  # deliberately executing a wrong MIL statement:
  my $sth = $dbh->prepare('( xyz 1);');
  eval { $sth->execute }; print "ERROR REPORTED: $@" if $@;
}
$dbh->do('var b:=new(int,str);');
$dbh->do('insert(b,3,"three");');
{
  # variable binding stuff:
  my $sth = $dbh->prepare('insert(b,?,?);');
  $sth->bind_param( 1,     7 , DBI::SQL_INTEGER() );
  $sth->bind_param( 2,'seven' );
  $sth->execute;
}
{
  my $sth = $dbh->prepare('print(b);');
  # get all rows one at a time:
  $sth->execute;
  while ( my $row = $sth->fetch ) {
    print "bun: $row->[0], $row->[1]\n";
  }
  # get all rows at once:
  $sth->execute;
  my $t = $sth->fetchall_arrayref;
  my $r = @$t;         # row count
  my $f = @{$t->[0]};  # field count
  print "rows: $r, fields: $f\n";
  for my $i ( 0 .. $r-1 ) {
    for my $j ( 0 .. $f-1 ) {
      print "field[$i,$j]: $t->[$i][$j]\n";
    }
  }
}
{
  # get values of the first column from each row:
  my $row = $dbh->selectcol_arrayref('print(b);');
  print "head[$_]: $row->[$_]\n" for 0 .. 1;
}
{
  my @row = $dbh->selectrow_array('print(b);');
  print "field[0]: $row[0]\n";
  print "field[1]: $row[1]\n";
}
{
  my $row = $dbh->selectrow_arrayref('print(b);');
  print "field[0]: $row->[0]\n";
  print "field[1]: $row->[1]\n";
}
$dbh->disconnect;
print "\nFinished\n";

Every SQL implementation differs in minor / major areas from the SQL standard. This calls for using middleware to translate queries, or even manually rewrite them according to the DBMS specifics.

A synopsis of the builtin functionality and comparison with related products, such as Postgresql, MySQL, and several commerical systems, can be found in the SQL wikibook.