This driver is an OTP-compliant PostgreSQL driver. Connections are OTP-supervised processes.
This implementation was initially inspired and derived from existing database drivers, and especially Will Glozer's and Christian Sunesson's PostgreSQL drivers, yet has eventually little in common with those. API and features are different.
In particular, this driver has the following features:
- OTP-supervision;
- transparently handling many PostgreSQL types, including arrays and numerics;
- cancellation of running queries using out-of-band protocol;
- SSL support;
- timeout for queries;
- iteration on results using protocol-level implicit portals and cursors, with fold, map and foreach;
- mapping of types to Erlang using a mapping of known types, handling new types that may arise through the life of the connection (this feature is an improvement of oidmap handling in Christian Sunesson's driver);
- handling both floating point and integer datetimes (this feature is an improvement of timestamp handling in Will Glozer's driver).
Driver can be compiled with rebar.
erlc -o ebin/ src/*.erl
also works.
The application must be started before connections can be made to a PostgreSQL server.
The main module is pgsql_connection
. Connections are opened with one of pgsql_connection:open/1,2,3,4,5
functions. Please refer to pgsql_connection.erl
for details.
For convenience with other database APIs, connection objects can be used as parametrized modules as connection objects are {pgsql_connection, pid()}
tuples. API functions taking a connection as the last parameter can be called with the connection as the parametrized module. For example, a connection can be closed with pgsql_connection:close(Connection)
or with Connection:close()
.
Two APIs are available. The current, "native" API is composed of the following functions:
Perform a simple query (in PostgreSQL parlance), i.e. a query with no parameter. Results are cast to Erlang-types. Text is returned as binaries (unicode:unicode_binary()
). Enums are typed {atom() :: TypeName, unicode:unicode_binary()}
. See tests (pgsql_connection_test.erl
) for details.
Perform an extended query, i.e. a query with bound parameters. Parameters must be represented in the query with $1, ..., $n placeholders. Most erlang types are supported. Binaries are passed as-is and are interpreted by PostgreSQL as text or binary depending on what is expected. Lists are interpreted as strings, arrays are represented as {array, [item()]}
. See tests (pgsql_connection_test.erl
) for details.
Perform an extended query several times with different parameters. Saves some network I/O with the server.
Perform an extended query and fold (resp. map, execute a function on each row). This opens an implicit cursor with the server and iterates on results.
Cancel the current running query. This opens a new connection to cancel the query (out-of-band cancelation).
The driver also has an ODBC-like interface, which is deprecated. It is composed of sql_query/2,3,4
, param_query/3,4,5
and utility function convert_statement/1
Besides cancelation, the driver supports what PostgreSQL documentation calls Asynchronous operations. Namely, it can receive several types of messages when the connection is idle or at any point in the protocol. This is especially meaningful for notifications and notices. These messages are ignored by default but can be sent to subscribers. To subscribe when opening a connection, simply use {async, pid()}
option. To subscribe later, use pgsql_connection:subscribe/2
. Subscribers can presently receive two types of Erlang messages:
{pgsql, Connection, {notice, Fields :: [{atom(), binary()}]}}
for notices, whereConnection
is the connection tuple and Fields describes the notice (typically including{severity, <<"NOTICE">>}
and{message, NoticeMessage}
).{pgsql, Connection, {notification, ProcID :: pos_integer(), Channel :: binary(), Payload :: binary()}}
for notifications, whereProcID
is the sender backend id.
Implementers of subscribers are encouraged to handle any message of the form {pgsql, Connection, _}
to cope with future features.
Tests require a user 'test' on postgres, with super privileges, and a test database. For example:
psql -h localhost -U postgres
create user test;
alter user test with superuser;
create database test with owner=test;
Copyright (c) 2009-2013, Semiocast. All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
- Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
- Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.