Backend Interface (BKI) files are scripts in a special language that are input to the Postgres backend running in the special bootstrap mode that allows it to perform database functions without a database system already existing. BKI files can therefore be used to create the database system in the first place. (And they are probably not useful for anything else.) initdb uses BKI files to do part of its job when creating a new database cluster. The input files used by initbd are created as part of building and installing Postgres by a program named genbki.sh from some specially formatted C header files in the source tree. The created BKI files are called global.bki (for global catalogs) and template1.bki (for the catalogs initially stored in the template1 database and then duplicated in every created database) and are normally installed in the share subdirectory of the installation tree. Related information may be found in the documentation for initdb. This section describes how the Postgres backend interprets BKI files. This description will be easier to understand if the global.bki file is at hand as an example. You should also study the source code of initdb to get an idea of how the backend is invoked. BKI input consists of a sequence of commands. Commands are made up of a number of tokens, depending on the syntax of the command. Tokens are usually separated by whitespace, but need not be if there is no ambiguity. There is not special command separator; the next token that syntactically cannot belong to the preceeding command starts a new one. (Usually you would put a new command on a new line, for clarity.) Tokens can be certain key words, special characters (parentheses, commas, etc.), numbers, or double-quoted strings. Everything is case sensitive. Lines starting with a # are ignored. open tablename Open the table called tablename for further manipulation. close tablename Close the open table called tablename. It is an error if tablename is not already opened. If no tablename is given, then the currently open table is closed. create tablename (name1 = type1 , name2 = type2, ...) Create a table named tablename with the columns given in parentheses. The type is not necessarily the data type that the column will have in the SQL environment; that is determined by the pg_attribute system catalog. The type here is essentially only used to allocate storage. The following types are allowed: bool, bytea, char (1 byte), name, int2, int2vector, int4, regproc, text, oid, tid, xid, cid, oidvector, smgr, _int4 (array), _aclitem (array). Array types can also be indicated by writing [] after the name of the element type. The table will only be created on disk, it will not automatically be registered in the system catalogs and will therefore not be accessible unless appropriate rows are inserted in pg_class, pg_attribute, etc. insert OID = oid_value (value1 value2 ...) Insert a new row into the open table using value1, value2, etc., for its column values and oid_value for its OID. If oid_value is zero (0) or the clause is ommitted, then the next available OID is used. NULL values can be specified using the special key word _null_. Values containing spaces should be double quoted. declare unique index indexname on tablename using amname (opclass1 name1 , ...) Create an index named indexname on the table named tablename using the amname access method. The fields to index are called name1, name2 etc., and the operator classes to use are opclass1, opclass2 etc., respectively. build indices Build the indices that have previously been declared. The following sequence of commands will create the test_table table with the two columns cola and colb of type int4 and text, respectively, and insert two rows into the table. create test_table (cola = int4, colb = text) open test_table insert OID=421 ( 1 "value1" ) insert OID=422 ( 2 _null_ ) close test_table