Backend Interface (BKI) files are scripts in a special language that is understood by the PostgreSQL backend when running in the bootstrap mode. The bootstrap mode allows system catalogs to be created and filled from scratch, whereas ordinary SQL commands require the catalogs to exist already. 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 a BKI file to do part of its job when creating a new database cluster. The input file used by initdb is created as part of building and installing PostgreSQL by a program named genbki.pl, which reads some specially formatted C header files in the src/include/catalog/ directory of the source tree. The created BKI file is called postgres.bki and is normally installed in the share subdirectory of the installation tree. Related information can be found in the documentation for initdb. This section describes how the PostgreSQL backend interprets BKI files. This description will be easier to understand if the postgres.bki file is at hand as an example. 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 no special command separator; the next token that syntactically cannot belong to the preceding 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 # are ignored. create tablename tableoid bootstrap shared_relation without_oids rowtype_oid oid (name1 = type1 FORCE NOT NULL | FORCE NULL , name2 = type2 FORCE NOT NULL | FORCE NULL , ...) Create a table named tablename, and having the OID tableoid, with the columns given in parentheses. The following column types are supported directly by bootstrap.c: bool, bytea, char (1 byte), name, int2, int4, regproc, regclass, regtype, text, oid, tid, xid, cid, int2vector, oidvector, _int4 (array), _text (array), _oid (array), _char (array), _aclitem (array). Although it is possible to create tables containing columns of other types, this cannot be done until after pg_type has been created and filled with appropriate entries. (That effectively means that only these column types can be used in bootstrapped tables, but non-bootstrap catalogs can contain any built-in type.) When bootstrap is specified, the table will only be created on disk; nothing is entered into pg_class, pg_attribute, etc, for it. Thus the table will not be accessible by ordinary SQL operations until such entries are made the hard way (with insert commands). This option is used for creating pg_class etc themselves. The table is created as shared if shared_relation is specified. It will have OIDs unless without_oids is specified. The table's row type OID (pg_type OID) can optionally be specified via the rowtype_oid clause; if not specified, an OID is automatically generated for it. (The rowtype_oid clause is useless if bootstrap is specified, but it can be provided anyway for documentation.) open tablename Open the table named tablename for insertion of data. Any currently open table is closed. close tablename Close the open table. The name of the table can be given as a cross-check, but this is not required. 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 omitted, and the table has OIDs, then the next available OID is assigned. NULL values can be specified using the special key word _null_. Values containing spaces must be double quoted. declare unique index indexname indexoid on tablename using amname ( opclass1 name1 , ... ) Create an index named indexname, having OID indexoid, 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. The index file is created and appropriate catalog entries are made for it, but the index contents are not initialized by this command. declare toast toasttableoid toastindexoid on tablename Create a TOAST table for the table named tablename. The TOAST table is assigned OID toasttableoid and its index is assigned OID toastindexoid. As with declare index, filling of the index is postponed. build indices Fill in the indices that have previously been declared. The open command cannot be used until the tables it uses exist and have entries for the table that is to be opened. (These minimum tables are pg_class, pg_attribute, pg_proc, and pg_type.) To allow those tables themselves to be filled, create with the bootstrap option implicitly opens the created table for data insertion. Also, the declare index and declare toast commands cannot be used until the system catalogs they need have been created and filled in. Thus, the structure of the postgres.bki file has to be: create bootstrap one of the critical tables insert data describing at least the critical tables close Repeat for the other critical tables. create (without bootstrap) a noncritical table open insert desired data close Repeat for the other noncritical tables. Define indexes and toast tables. build indices There are doubtless other, undocumented ordering dependencies. The following sequence of commands will create the table test_table with OID 420, having two columns cola and colb of type int4 and text, respectively, and insert two rows into the table: create test_table 420 (cola = int4, colb = text) open test_table insert OID=421 ( 1 "value1" ) insert OID=422 ( 2 _null_ ) close test_table