WDB User's Manual


WDB is a database system designed to store MHO (Meteorological, Hydrological and Oceanographic) data in a PostgreSQL database management server. The purpose of the WDB system is to improve the quality and effectiveness of IT systems for MHO production by providing a complete, flexible, and effective data storage solution for real-time and archive data.

This is the User's Manual for the core WDB system.

WDB is a storage system for meteorological, hydrological, and oceanographic data, including physical and chemical data, but excluding biological/environmental data. It is primarily designed to store field data (meteorological forecasts and analysis, oceanographic wave and circulation models) as well as observations and point forecasts. The purpose of the WDB system is to improve the quality and effectiveness of IT systems for MHO production by providing a flexible and effective data storage solution for real-time and archive data

WDB is an open-source system built on the PostgreSQL object-relational database management system. Key features of the system are that it:

  • supports high availability production
  • can handle most types of meteorological, hydrological, and oceanographic data
  • is flexible enough to be extended with new data types and data formats
  • is easy (and cheap) to maintain and operate
  • provides a simple and consistent interface to all the different kinds of data

As WDB is released under GPL, it may be used, modified, and distributed by anyone free of charge for any purpose, be it private, commercial or academic.

The WDB system was initially developed by Meteorologisk institutt, Norway (met.no) from 2006-2008. WDB is a descendant of the ROAD system, a real-time operational database system developed at Sveriges Meteorologiska och Hydrologiska Institut (SMHI).

In addition to the manuals, there are (or will be) other resources available on WDB:

  • The WDB web site, http://wdb.met.no contains information about the latest release and lots of other information to make your work (or play) with WDB more productive.
  • The mailing lists is monitored by the WDB developers. We try to respond to questions as much as time allows.

When you find a bug in WDB, we want to hear about it. The best solution at the moment is to contact us on the appropriate mailing list (usually wdb-users@list.sourceforge.net).

In this section, we will briefly describe the basic architecture of the WDB system. Understanding the architecture of WDB will help make the following sections somewhat clearer.

At its core, the WDB system consists of a database management server (built on the PostgreSQL DBMS), a number of utilities for maintenance and data loading, and a function interface for data extraction. We refer to the data loading utilities as loading programs and the data extraction interface as the WDB Call Interface (WCI). The figure below illustrates the relation of the different components of WDB.

Overview of the WDB Architecture

We refer to the WDB data model together with the WDB Call Interface as the WDB core. This comprises the data storage components of the database along with the interface to read and write data. The WDB Call Interface (WCI) is essentially a database module that provides the application developer or user with a function-based interface that can be used to extract data from WDB. This function interface is accessible through SQL, which means that any programming language capable of querying a PostgreSQL database can access data through WCI; at least in theory. Users of a WDB database never access the tables or views of the database directly; all access goes through WCI functionality.

The loading programs are utilized to extract data from the data sources (typically files or some network service) and load them into the database. In principle, each type of data: GRIB, FELT (an internal data format used at met.no), BUFR, etc., will have its own loading programs. The options and interfaces to the various loading programs are designed to be as similar to each other as possible, however.

The maintenance utilities are used for a variety of tasks related to the administration of the database, such as data cleaning (removing data that is no longer required), creating and deleting users, and checking on the status of the system.

Before you can use WDB, you need to install it. If you are not sure whether WDB is available on your site, or whether you can use it for your needs, you can install it yourself. WDB can be installed by any unprivileged user; superuser (root) access is not required (though some database privileges are required). If you are installing WDB yourself from a source package, then refer to Section Installation for the detailed installation instructions, and return to this guide when the installation is complete.

Checking the Configuration

If your site administrator has not set WDB up in a default way, you may have a little work to do checking and setting up your environment variables. If WDB has been installed correctly, you should have access to the wdbConfiguration utility. This can be used to verify the configuration of your system.

> wdbConfiguration
database =      mywdb
host =          localhost
port =          5432
user =          myuser

This tells you what the default connection information of your WDB database is assumed to be. If these are incorrect, you can change your settings by editing the wdb.conf.ex file installed in the WDB data directory (usually /usr/local/share/wdb and saving it to $(HOME)/.wdb

If you are unsure as to whether the connection information is correct, run:


wdb runs the administrative interface to a WDB database. Like all WDB utilities, it will attempt to connect to the database using the connection information stored in your wdb.conf file, unless alternative connection parameters are given on the command line. If the wdb utility is unable to connect to the database, something is wrong with your connection options. Check whether your database server is running. If the database server is down, then obviously you can not connect to it. Otherwise, you may need to consult your site administrator (or if that is you) the PostgreSQL documentation to make sure that your database environment is set up correctly.

Since version 1.2.0, it should be possible to upgrade WDB without deleting the data currently residing in the database using the upgrade scripts. Currently, the system is only upgradeable in direct progression; i.e., from one version to the immediately following version (this is the only scenario tested by WDB's test framework). So version 1.1.3 will upgrade 1.1.2 but there is no guarantee that 1.1.3 will upgrade from 1.1.1 unless the latter is first upgraded to 1.1.2.

Note that there is never any guarantee for upgrades from one major upgrade to the next. For these upgrade, a full install is assumed.

It is strongly recommended to ensure that you have a recent backup of your database before upgrading the system. The upgrade process cannot roll back automatically.

To upgrade from a source package, you can run the following commands from your build directory:

> ./configure
> make
> make install

WDB can also be upgraded using the upgrade functionality from Debian packages.

Data is loaded into WDB using one of the loading programs. Most of the loading programs have a file interface; in addition, several of them can be set up as persistent loading processes.

Each of the loading programs has its own manual page; consult the Loading Programs User Manual for details. In addition, all executable WDB components have the –help option implemented to provide extensive information about the options available to the program. In this section, we will just briefly go over the broad details.

Loading GRIB files

The gribLoad utility is used to load GRIB files into the database. It takes as input the name of the file(s) as well as a number of options, decodes the GRIB file using the cross-reference metadata for GRIB in WDB, and stores the fields from the GRIB file in WDB. The GRIB loading program is invoked by typing gribLoad and the filename from the command line.

> gribLoad myfile.grib

This loads the GRIB file myfile.grib into the WDB database using the default parameters for the gribLoad utility. If the database configuration is not the default, you will want to specify the correct configuration using the available options. For example:

> gribLoad -d mywdb -u myuser -p 5433 myfile.grib

This loads the GRIB file into the database “mywdb” on port “5433”, with the database user “myuser”. For the full list of options available with the gribLoad utility, use the –help option or check the GribLoad documentation.

Note that the gribLoad utility works together with wildcards. For example, you could use the command:

> gribLoad *.grib

This would load every file in the current directory with the “grib” suffix into the database one after the other. Note, though, that if you have a system with multiple processors and good enough disks, you will be able to achieve significantly better loading performance by loading several files in parallel.

To access data in WDB, one needs to go through the WDB Call Interface (WCI). WCI is a data-retrieval API implemented using SQL functions.

WDB Call Interface

To use the WCI, the user connects to the database through any SQL interface and then retrieves data using the WCI functions. This means that, in theory, data can be retrieved through the WCI from any programming language or program that supports SQL queries to a PostgreSQL database server. For the example below, we will assume a connection to PostgreSQL through a psql client interface.

To retrieve data from WCI through SQL, you need to understand three (two) functions:


The wci.begin function call “opens” up the connection to the WCI. In practice, it sets up a number of internal variables in the database and checks that your user has permission to read and/or write from WCI. The wci.begin call must be called before any other WCI functions are called.

mywdb=# select wci.begin('myuser');

This functionality may be deprecated in a future version of the database.


The wci.read call is the key function call in the WCI used to retrieve data from the database. In WDB, data is classified by a number of dimensions; the dataprovider (the source that provided the data), the location of the data (and what geographical interpolation to use), the reference time (time of reference for the data), the valid time (the time for which the data is valid), the value parameter (the “MHO parameter” that identifies the data values in the database, the level for which the data is valid (height, depth, etc.) and finally the version of the data (data can exist in multiple versions). Each of these dimensions can be passed as a parameter to the wci.read function. In addition, the wci.read function also takes as a parameter the type of data to be returned.

mywdb=# select *
	from wci.read ( ARRAY['hirlam norway'], -- Data Provider
		'POLYGON((10 60,11 60,11 61,10 61,10 60))', -- Location
		'1980-01-01 12:00:00',  -- Reference time
		'inside 1980-01-02 00:00:00 TO 1980-01-03 00:00:00', -- Valid time
		ARRAY['air temperature'], -- Value Parameter
		'2 height', -- Level
		ARRAY[-1], -- Data version
		NULL::returnFloat   -- Return type

Specifying a NULL for a dimension, corresponds to asking for all data of that kind. For example:

mywdb=# select *
	from wci.read ( ARRAY['hirlam norway'], -- Data Provider
		'POLYGON((10 60,11 60,11 61,10 61,10 60))', -- Location
		'1980-01-01 12:00:00',  -- Reference time
		'inside 1980-01-02 00:00:00 TO 1980-01-03 00:00:00', -- Valid time
		NULL, -- All parameters
		NULL, -- Any level
		NULL, -- All data versions
		NULL::returnFloat -- Return type

This query would return all data for the location, reference time, and valid time specified, irrespective of what value parameter, level, or data version the data is recorded with. If you're retrieving data and know that there is only one or very few values possible for a given dimension (e.g., retrieving data with only one data version value in the database), it will usually be more efficient to set the dimension in the wci.read dimension to NULL rather than specifying the value explicitly.

The wci.read call permits great flexibility in the specification of queries, allowing the user to extract individual records in the database or thousands of records. Data can also be extracted as points (as above), or entire fields of data.


The wci.end call “closes” down the connection to the WCI, and resets any internal variables that may have been changed by the WCI. It is, strictly speaking, not necessary to call wci.end if you subsequently close down the database connection (as this will drop all the settings anyway), but not doing so can lead to problems if you subsequently continue working on the same connection.

mywdb=# select wci.end( );

For a more thorough description of the functionality in the WDB Call Interface, consult the wdb_call_interface.

This function will be deprecated in future.

The quick way to install the WDB system is simply to do the following (this requires that your system has all of the prerequisites for the WDB system installed and operational).

Retrieve the desired version of the WDB source from the [https://github.com/wdb/wdb/tags|WDB Github]. Unpack the source package to a suitable directory, and from this directory run:

> ./autogen.sh
> ./configure
> make
> make install

If you have everything in place, this will build and install WDB. The rest of this section discusses the details of the requirements for building WDB.

In general, WDB should be possible to run on any modern, Unix-compatible platform that is capable of running PostgreSQL. However, it has only tested on platforms as described in Supported Platforms.

Required Packages

The following software packages are required for building WDB:

Unpackaging software

GNU tar or similar archiving software able to handle tar.gz files is required to unpack the source distribution in the first place, in addition to either gzip or bzip2.

C++ Compiler

You need an ISO/ANSI C++ compiler. We recommend a recent version of gcc or g++, but WDB should compile with most variants of compilers.

GNU make

GNU make or another, compatible, make program is required. WDB is developed and tested using GNU make version 3.80. There is no reason why it should not work with earlier versions, but obviously there are no guarantees.

Gnu automake and libtool

WDB is built using the GNU autoconf/automake/libtool build system. It should be compatible with automake 2.61 or later versions.

GNU sed

GNU sed version 4.1.5 or later is used for performing text transformations on the WDB system files. If you need to get a GNU package, you can find it at your local GNU mirror site (see http://www.gnu.org/order/ftp.html for a list) or at ftp://ftp.gnu.org/gnu/.

GNU readline

GNU readline version 5.x or later is used for handling of command line inputs in the WDB administration tools. If you need to get a GNU package, you can find it at your local GNU mirror site (see http://www.gnu.org/order/ftp.html for a list) or at ftp://ftp.gnu.org/gnu/.


GLib version 2.24.0 or later is used for compiling WDB.


You must have access to a PostgreSQL 8.4.x (or later version) server, to be able to install a WDB server. WDB utilizes the pg_config utility to retrieve information about your installed version of PostgreSQL, so take care to ensure the right version of pg_config is in your path if you have multiple versions of the database server installed. If you need to download PostgreSQL, see http://www.postgresql.org.


PostGIS 1.1.x or later is used for the geographical objects stored in WDB. The WDB installation scripts utilize pg_config to determine the location of the PostGIS scripts, so care should be taken that PostGIS is installed correctly (i.e., in the SHAREDIR of PostgreSQL; this installation is however not consistent across all versions of PostgreSQL and PostGIS). If you need to download PostGIS, see http://www.postgis.org


Geos 3.1.x or later is used for the handling of shapes and points that are done in the WDB source code.


Proj 4.6.x or later is used for the geographical transformations that are done in the WDB source code.


Boost libraries version 1.33.1 or later are required to compile a number of the programs in WDB. Boost can be downloaded from http://www.boost.org


Log for C++ (Log4Cpp) 1.0.0 or later is utilized for the logging functionality in WDB. It can be downloaded from http://log4cpp.sourceforge.net/


Package used to manage compile and link flags for libraries.


xmlto is used to build the documentation of the WDB project.

Optional Packages

The following software packages are optional. It is possible to compile WDB without these packages, but certain options will then be disabled, as explained below.


CppUnit version 1.x.x or later is used for the unit tests of WDB and some of the installation and performance test programs. WDB can be compiled, installed and run without these programs, but the tests will be unavailable without this package. CppUnit can be downloaded from http://www.boost.org.

Currently, WDB is only extensively tested on Ubuntu Lucid and developed on the same environment. There is no reason that we know of why it should not be able to run on any Linux OS with the prerequisite packages installed.

You can examine the systems against which WDB is currently being tested (and thus supports) by checking the WDB buildbot (when available).

You may wish to verify that you have sufficient disk space. The compiled source for WDB requires approximately 120 MB and an empty PostgreSQL installation with WDB can rapidly take up to 200 MB of disk space (more if installation tests are run).

The first step of the installation procedure is to retrieve and unpack the source files for WDB. Once this has been done, you can configure the package.


First, you will need to configure the source tree for your system and select your build options.This is done by building and running the configure script. To build the configure script (if it is not already built), run:

> ./autogen.sh

This will build the configure script. For a default installation simply enter:

> ./configure

This script will run a number of tests to guess values for various system dependent variables, detect quirks of your operating system, and finally will create several files in the build tree to record what it found. (You can also run configure in a directory outside the source tree if you want to keep the build directory separate). Once the script has completed running, it will print out the settings for your system.

The default configuration will build the WDB database and administration utilities, as well as the GribLoad loading program. All files will be installed under /usr/local by default.

You can customize the build and installation process by supplying one or more of the following command line options to configure:


Install all files under the directory PREFIX instead of /usr/local. The actual files will be installed into various subdirectories; no files will ever be installed directly into the PREFIX directory.

If you have special needs, you can also customize the individual subdirectories with the following options. However, if you leave these with their defaults, the installation will be relocatable, meaning you can move the directory after installation. The man and doc locations are not affected by this.

To install WDB in a local directory (as you must, if you do not have root access), you could use:

> ./configure --prefix=/home/myuser/local

You can install architecture-dependent files under a different prefix, EXEC-PREFIX, than what PREFIX was set to. This can be useful to share architecture-independent files between hosts. If you omit this, then EXEC-PREFIX is set equal to PREFIX and both architecture-dependent and independent files will be installed under the same tree, which is probably what you want.


This specifies the directory for executable programs. The default is EXEC-PREFIX/bin, which normally means /usr/local/bin.


This specifies the directory for read-only data files used by the installed programs. The default is PREFIX/share.


This specifies the directory for various configuration files, PREFIX/etc by default.


This specifies the location to install libraries and dynamically loadable modules. The default is EXEC-PREFIX/lib.


This specifies the directory for installing C and C++ header files. The default is PREFIX/include.


The man pages that come with WDB will be installed under this directory, in their respective manx subdirectories. The default is PREFIX/man.

If configure is having difficulty finding a particular library or supporting component, you can assist it by asking it to search a particular path.


This specifies the directory into which PostgreSQL is installed (by default, WDB searches your PATH environment variable). WDB is searching for the pg_config application and will search DIRECTORY/bin when this option is specified. pg_config provides detailed information about your installed version of PostgreSQL. If you have multiple installations of PostgreSQL, make sure that the pg_config used by WDB is for the intended version of PostgreSQL.


This specifies the directory into which Postgis installs its SQL setup files (lwpostgis.sql and spatial_ref_sys.sql). By default, this should be the location used for architecture-independent support files by PostgreSQL, given by “pg_config –sharedir”. Unfortunately, not all versions of Postgis handle the installation of these files in a standard manner. To ensure that WDB is able to locate those files, set the directory to be searched with this option.


This specifies the directory into which Boost has been installed. If set, WDB will add DIRECTORY/include and DIRECTORY/lib to its search space when searching for the header and library files of Boost.


WDB uses the date-time library of Boost. By setting this option, you can instruct the linker to utilize a specific version of the library; e.g.

  1. -with-boost-date-time=boost_date_time-gcc-mt-d-1_33_1

WDB uses the regex library of Boost. By setting this option, you can instruct the linker to utilize a specific version of the library; e.g.

  1. -with-boost-regex=boost_regex-gcc-mt-d-1_33_1

This specifies the directory into which Proj has been installed. If set, WDB will add DIRECTORY/include and DIRECTORY/lib to its search space when searching for the header and library files of Proj.


This specifies the directory into which the cppunit-config application has been installed (by default, WDB searches your PATH environment variable). CppUnit is an optional module; it is only required for the compilation of the test framework.


This specifies the directory into which the cppunit-config application has been installed (by default, WDB searches your PATH environment variable). CppUnit is an optional module; it is only required for the compilation of the test framework.


This specifies the directory into which the docbook processor used by WDB, xmlto, is installed (by default, WDB searches your PATH environment variable). If DIRECTORY is set, configure will in addition search through DIRECTORY/bin.

Environment Variable

If you prefer a C++ compiler different from the one configure picks, you can set the environment variable CXX to the program of your choice. By default, configure will pick gcc if available, else the platform's default (usually cc). Similarly, you can override the default compiler flags if needed with the CXXFLAGS variable.

You can specify environment variables on the configure command line, for example:

> ./configure CXX=/opt/bin/gcc CXXFLAGS='-O2 -Wno-deprecated'

The following are the significant variables that can be set in this manner:

  • CC = The C compiler
  • CXX = The C++ compiler
  • CPPFLAGS = Options to pass to the C/C++ compiler
  • LDFLAGS = Options to pass to the linker
  • PKG_CONFIG = The path to the pkg_config utility.


To build WDB, run:

> make

A cup of coffee around now might be appropriate, depending on your hardware.


To install WDB, verify that your database server is running, and then enter:

> make install

This will install files into the directories that were specified during configuration. Ensure that you have appropriate permissions to write into that area (if this is /usr/local, you will normally have to do this step as root). Alternatively, you could create the target directories in advance and arrange for appropriate permissions to be granted.

You can use make install-strip instead of make install to strip the executable files and libraries as they are installed. This will save some space. If you built with debugging support, stripping will effectively remove the debugging support, so it should only be done if debugging is no longer needed. install-strip tries to do a reasonable job saving space, but it does not have perfect knowledge of how to strip every unneeded byte from an executable file, so if you want to save all the disk space you possibly can, you will have to do manual work.

Note that installation, in particular the loading of the database with metadata, can take a few minutes.


If you want to test the newly built system that you just installed, you can run the regression test suite. This involves two parts: the unit tests (which can be run prior to the installatuion) and the installation tests. The test suite can be used to verify that WDB runs on your system the way the developers expected it to. Type:

> make check installcheck


To undo the installation, simply type

> make uninstall

Note, however that this will not remove directories created by the installation.


After the installation, you can make room on your drives by removing the built files from your source tree by typing:

> make clean

This will preserve the files made by the configure program, so you will still be able to run make later on. To clean out everything, use:

> make distclean

If you perform a build and discover that your configure options were wrong, you changed some option that WDB utilizes (e.g., upgraded software), or you need to build for several platforms using the same source tree, it can be a good idea to use distclean before reconfiguring and building.

In the following sections, we describe the system administration functionality that is available with WDB.

The generic administration utility of the WDB system is the wdb utility.

> wdb

This will bring up the wdb command line interface. From this interface, the user can type 'help' to get a list of the available commands. The wdb utility can be used to carry out a number of the most common administrative tasks.

The wdb utility can also be invoked directly from the command line. Thus:

> wdb help

This will print out a list of the available commands and exit the utility.

User management in WDB is implemented on top of the user authentication in PostgreSQL. By default, PostgreSQL is usually set up to accept local connections using the 'trust' method. This means that any local user can connect to the database as any PostgreSQL user, including the database superuser. To change this and switch on client authentication, have the database administrator consult the PostgreSQL Administrator's Guide, chapter “Client Authentication”.

Currently, the WDB system does not support use of password authentication in its various utilities.

WDB users can belong to one or more of three different groups: wdb_admin, wdb_read, and wdb_write.


This is the administrator/superuser group for WDB. The WDB user must belong to this group in order to perform administrative acions in the database.


This is the default user group for WDB users. It allows the user to read data from the database through WCI functions.


This is the user group that one must belong to in order to be able to load data into the database using the WCI functions or the loading programs. The WDB user that runs the loading programs must belong to the wdb_write group.

Observe that the PostgreSQL superuser for the database always has full access to all of these groups.

The wdb utility can be utilized to create, drop, or modify WDB users.

> wdb createuser mywdbuser

This will create a user, 'mywdbuser', with the default user settings (wdb_read). The administrator can also specify precisely the settings that they would like to assign. The following command will create a user 'mywdbuser', with the wdb_write group (the 'noread' command is used to remove the 'wdb_read' group that would otherwise be assigned by default.

> wdb createuser mywdbuser write noread

To drop a user, replace the command as appropriate:

> wdb dropuser mywdbuser

It is also possible to change a users attributes after they have been created. To do so, use the 'changeuser' command as follows.

> wdb changeuser mywdbuser write read

This gives 'mywdbuser' the wdb_read and wdb_write roles. If the user previously had the wdb_admin role, it would have been removed.

===== Data Description ====?

The community at which WDB is directed (meteorology, hydrology, oceanography) has, literally, hundreds of different metadata standards. Consequently, the internal data description language (i.e., metadata) of WDB, is built on a generic template to ensure maximum flexibility.

The following section will describe the data description language of WDB in detail, as well as discuss how to modify it and keep it up to date.

At its core, the description of data in WDB reflects a dimensional model, where the value of the data are the facts, while the various parameters: data provider, location, reference time, valid time, value parameter, level parameter and level measure, confidence code/quality, storage time, etc. reflect the dimensions of the model.

Of these many dimensions, four require some maintenance of the metadata in the database.

Data Provider

The Data Provider of a data value, represents the source closest to the creation of the data that we can identify from the database. In order to load data into the database, the data source should be represented in the metadata of the database.

Data Provider metadata must currently be maintained in the database manually. See the relevant loading program system design notes for details.

Place Definition

The Place Definition of a data value describes the location for which that data value is valid. This is usually either a point or a grid (for data matrices).

Data Provider metadata must currently be maintained in the database manually. See the relevant loading program system design notes for details.

Value Parameter

The Value Parameter represents the meteorological, hydrological, or oceanographic parameter that describes the data value.

Level Parameter

The Level Parameter describes the level value associated with the data value.

WDB contains a data cleaning utility which can be used to clean out old data. This section will contain a description of the cleaning program, as well as how it is used.

The current version of the data cleaning utility, however, is not suitable for production usage. It is therefore not recommended to make use of it.


wdb - WDB administration utility. It is a part of the WDB system.




wdb is a terminal based tool for monitoring and controlling the WDB system.


If invoked without any arguments, the utility will attempt to connect to the database program with the default arguments available.


Produces the help message and then exits.


Produce version information and then exits.


Set output logfile. The default is to print to stdout

–loglevel LEVEL

Sets the logging level, from 1 (most) to 5 (least)

-d DBNAME, –database=DBNAME

Specify the database name to connect to (e.g., wdb).


Specify the database host to connect to (e.g., somehost.met.no).


Specify the WDB user to connect as. The database user must have access to the wdb_grib role (this is will usually be the case if the gribLoad process is being run by the creator of the database).


Specify the database port to connect to (e.g., 5432).


wdbConfiguration — Get information related to wdb database settings


“wdbConfiguration” [OPTION]


The purpose of wdbConfiguration is to provide information about the wdb database setup. The information provided should be enough to connect to the database, appart from authentication and authorization.

If invoked without any arguments, the program will list database host, port, along with the user name any wdb-related applications will use unless told otherwise. It is also possible to request the output of a single of these parameters. This is done by using one of the following commands:


Get database name


Get the database host


Get default database user name


Get the database port number to connect to

In addition, it is also possible to specify an output format. If none is given, the output format will match the format of the wdb.conf files.


Get arguments to connect to the database using psql (You may e.g say psql `wdbConfiguration –psqlArgs`)


Get the connection parameter to connect to the database using libpqxx

Other options are:


Read additional configuration from the given file. The information in the provided file will take precedence over other configuration sources (eg. “/etc/wdb.conf”).


Display a help message, wiht a summary of command line options.


Display version information, then exit


wdb.conf - Information about wdb database configuration


The wdb.conf file contains database configuration for wdb. This includes the database's host, port and name. Also, the file may contain a default username for connections.

The file contains one or more “key = value” statements, separated by newlines. Comments may be inserted using a #. Allowed keys in wdb.conf are:


Database name. Defaults to 'wdb'.


Database host, either as a network address, or as a local folder. If unspecified, wdb connection will be created using unix filesystem sockets, using postgresql's default socket directory. If a folder in the file system is specified, that folder will be used instead.


What port to connect to. Default value is postgresql's default port (5432).


Database user name defaults to environment variable $USER


A global configuration file is normally placed in “PREFIX/etc/wdb.conf”. It is also possible to place a local configuration file in “$HOME/.wdb/wdb.conf”. All key mentioned here will override keys mentioned in the global file, but other values in the global file will remain unchanged.

I addition to this, every wdb application has an options for overriding the configuration, including to read another config file.

Example file

An example wdb.conf file can be found at “ WDB_DATADIR/wdb/wdb.conf.ex”.

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • wdb/manuals/wdb.txt
  • Last modified: 2022-05-31 09:29:32
  • (external edit)