Boolean Type

PostgreSQL provides the standard SQL type boolean; see Table 8-19. The boolean type can have several states: "true", "false", and a third state, "unknown", which is represented by the SQL null value. Table 8-19. Boolean Data Type Name Storage Size Description boolean 1 byte state of true or false Valid literal values for the "true" state are: TRUE 't' 'true' 'y' 'yes' 'on' '1' For the "false" state, the following values can be used: FALSE 'f' 'false' 'n' 'no' 'off' '0' Leading or traili

bloom

bloom provides an index access method based on Bloom filters. A Bloom filter is a space-efficient data structure that is used to test whether an element is a member of a set. In the case of an index access method, it allows fast exclusion of non-matching tuples via signatures whose size is determined at index creation. A signature is a lossy representation of the indexed attribute(s), and as such is prone to reporting false positives; that is, it may be reported that an element is in the set, w

Bit String Types

Bit strings are strings of 1's and 0's. They can be used to store or visualize bit masks. There are two SQL bit types: bit(n) and bit varying(n), where n is a positive integer. bit type data must match the length n exactly; it is an error to attempt to store shorter or longer bit strings. bit varying data is of variable length up to the maximum length n; longer strings will be rejected. Writing bit without a length is equivalent to bit(1), while bit varying without a length specification means

Bit String Functions and Operators

This section describes functions and operators for examining and manipulating bit strings, that is values of the types bit and bit varying. Aside from the usual comparison operators, the operators shown in Table 9-13 can be used. Bit string operands of &, |, and # must be of equal length. When bit shifting, the original length of the string is preserved, as shown in the examples. Table 9-13. Bit String Operators Operator Description Example Result || concatenation B'10001' || B'011' 10001

Binary String Functions and Operators

This section describes functions and operators for examining and manipulating values of type bytea. SQL defines some string functions that use key words, rather than commas, to separate arguments. Details are in Table 9-11. PostgreSQL also provides versions of these functions that use the regular function invocation syntax (see Table 9-12). Note: The sample results shown on this page assume that the server parameter bytea_output is set to escape (the traditional PostgreSQL format). Table 9-

Binary Data Types

The bytea data type allows storage of binary strings; see Table 8-6. Table 8-6. Binary Data Types Name Storage Size Description bytea 1 or 4 bytes plus the actual binary string variable-length binary string A binary string is a sequence of octets (or bytes). Binary strings are distinguished from character strings in two ways. First, binary strings specifically allow storing octets of value zero and other "non-printable" octets (usually, octets outside the range 32 to 126). Character strings

BEGIN

NameBEGIN -- start a transaction block Synopsis BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ] where transaction_mode is one of: ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ UNCOMMITTED } READ WRITE | READ ONLY [ NOT ] DEFERRABLE Description BEGIN initiates a transaction block, that is, all statements after a BEGIN command will be executed in a single transaction until an explicit COMMIT or ROLLBACK is given. By default (without BEG

auto_explain

The auto_explain module provides a means for logging execution plans of slow statements automatically, without having to run EXPLAIN by hand. This is especially helpful for tracking down un-optimized queries in large applications. The module provides no SQL-accessible functions. To use it, simply load it into the server. You can load it into an individual session: LOAD 'auto_explain'; (You must be superuser to do that.) More typical usage is to preload it into some or all sessions by includin

auth_delay

auth_delay causes the server to pause briefly before reporting authentication failure, to make brute-force attacks on database passwords more difficult. Note that it does nothing to prevent denial-of-service attacks, and may even exacerbate them, since processes that are waiting before reporting authentication failure will still consume connection slots. In order to function, this module must be loaded via shared_preload_libraries in postgresql.conf. F.2.1. Configuration Parameters auth_dela

Authentication Problems

Authentication failures and related problems generally manifest themselves through error messages like the following: FATAL: no pg_hba.conf entry for host "123.123.123.123", user "andym", database "testdb" This is what you are most likely to get if you succeed in contacting the server, but it does not want to talk to you. As the message suggests, the server refused the connection request because it found no matching entry in its pg_hba.conf configuration file. FATAL: password authenticatio