PostgreSQL database is Open Source product and available without cost. Postgres, developed originally in the UC Berkeley Computer Science Department, pioneered many of the object-relational concepts now becoming available in some commercial databases. It provides SQL92/SQL99 language support, transactions, referential integrity, stored procedures and type extensibility. PostgreSQL is an open source descendant of this original Berkeley code.
To use PostgreSQL support, you need PostgreSQL 6.5 or later, PostgreSQL 8.0 or later to enable all PostgreSQL module features. PostgreSQL supports many character encoding including multibyte character encoding. The current version and more information about PostgreSQL is available at http://www.postgresql.org/ and the PostgreSQL Documentation.
In order to enable PostgreSQL support, --with-pgsql[=DIR] is required when you compile PHP. DIR is the PostgreSQL base install directory, defaults to /usr/local/pgsql. If shared object module is available, PostgreSQL module may be loaded using extension directive in php.ini or dl() function.
The behaviour of these functions is affected by settings in php.ini.
Table 1. PostgreSQL configuration options
|pgsql.auto_reset_persistent||"0"||PHP_INI_SYSTEM||Available since PHP 4.2.0.|
|pgsql.ignore_notice||"0"||PHP_INI_ALL||Available since PHP 4.3.0.|
|pgsql.log_notice||"0"||PHP_INI_ALL||Available since PHP 4.3.0.|
Here's a short explanation of the configuration directives.
Whether to allow persistent Postgres connections.
The maximum number of persistent Postgres connections per process.
The maximum number of Postgres connections per process, including persistent connections.
Detect broken persistent links with pg_pconnect(). Needs a little overhead.
Whether or not to ignore PostgreSQL backend notices.
Whether or not to log PostgreSQL backends notice messages. The PHP directive pgsql.ignore_notice must be off in order to log notice messages.
Using the PostgreSQL module with PHP 4.0.6 is not recommended due to a bug in the notice message handling code. Use 4.1.0 or later.
PostgreSQL function names will be changed in 4.2.0 release to confirm to current coding standards. Most of new names will have additional underscores, e.g. pg_lo_open(). Some functions are renamed to different name for consistency. e.g. pg_exec() to pg_query(). Older names can be used in 4.2.0 and a few releases from 4.2.0, but they may be deleted in the future.
Table 2. Function names changed
Not all functions are supported by all builds. It depends on your libpq (The PostgreSQL C Client interface) version and how libpq is compiled. If there is missing function, libpq does not support the feature required for the function.
It is also important that you do not use an older libpq than the PostgreSQL Server to which you will be connecting. If you use libpq older than PostgreSQL Server expects, you may have problems.
Since version 6.3 (03/02/1998) PostgreSQL uses unix domain sockets by default. TCP port will NOT be opened by default. A table is shown below describing these new connection possibilities. This socket will be found in /tmp/.s.PGSQL.5432. This option can be enabled with the '-i' flag to postmaster and its meaning is: "listen on TCP/IP sockets as well as Unix domain sockets".
Table 3. Postmaster and PHP
|postmaster -i &||pg_connect("dbname=MyDbName");||OK|
|postmaster &||pg_connect("host=localhost dbname=MyDbName");||Unable to connect to PostgreSQL server: connectDB() failed: Is the postmaster running and accepting TCP/IP (with -i) connection at 'localhost' on port '5432'? in /path/to/file.php on line 20.|
|postmaster -i &||pg_connect("host=localhost dbname=MyDbName");||OK|
A connection to PostgreSQL server can be established with the following value pairs set in the command string: $conn = pg_connect("host=myHost port=myPort tty=myTTY options=myOptions dbname=myDB user=myUser password=myPassword ");
The previous syntax of: $conn = pg_connect ("host", "port", "options", "tty", "dbname") has been deprecated.
Environmental variables affect PostgreSQL server/client behavior. For example, PostgreSQL module will lookup PGHOST environment variable when the hostname is omitted in the connection string. Supported environment variables are different from version to version. Refer to PostgreSQL Programmer's Manual (libpq - Environment Variables) for details.
Make sure you set environment variables for appropriate user. Use $_ENV or getenv() to check which environment variables are available to the current process.
Note: PostgreSQL automatically folds all identifiers (e.g. table/column names) to lower-case values. To get it to recognize upper-case values, you must always wrap the identifier in quotes.
The constants below are defined by this extension, and will only be available when the extension has either been compiled into PHP or dynamically loaded at runtime.
Passed to pg_fetch_array(). Return an associative array of field names and values.
Passed to pg_fetch_array(). Return a numerically indexed array of field numbers and values.
Passed to pg_fetch_array(). Return an array of field values that is both numerically indexed (by field number) and associated (by field name).
Passed to pg_connect() to force the creation of a new connection, rather then re-using an existing identical connection.
Returned by pg_connection_status() indicating that the database connection is in an invalid state.
Returned by pg_connection_status() indicating that the database connection is in a valid state.
Passed to pg_lo_seek(). Seek operation is to begin from the start of the object.
Passed to pg_lo_seek(). Seek operation is to begin from the current position.
Passed to pg_lo_seek(). Seek operation is to begin from the end of the object.
Returned by pg_result_status(). The string sent to the server was empty.
Returned by pg_result_status(). Successful completion of a command returning no data.
Returned by pg_result_status(). Successful completion of a command returning data (such as a SELECT or SHOW).
Returned by pg_result_status(). Copy Out (from server) data transfer started.
Returned by pg_result_status(). Copy In (to server) data transfer started.
Returned by pg_result_status(). The server's response was not understood.
Returned by pg_result_status(). A nonfatal error (a notice or warning) occurred.
Returned by pg_result_status(). A fatal error occurred.
Returned by pg_transaction_status(). Connection is currently idle, not in a transaction.
Returned by pg_transaction_status(). A command is in progress on the connection. A query has been sent via the connection and not yet completed.
Returned by pg_transaction_status(). The connection is idle, in a transaction block.
Returned by pg_transaction_status(). The connection is idle, in a failed transaction block.
Returned by pg_transaction_status(). The connection is bad.
Passed to pg_result_error_field(). The severity; the field contents are ERROR, FATAL, or PANIC (in an error message), or WARNING, NOTICE, DEBUG, INFO, or LOG (in a notice message), or a localized translation of one of these. Always present.
Passed to pg_result_error_field(). The SQLSTATE code for the error. The SQLSTATE code identifies the type of error that has occurred; it can be used by front-end applications to perform specific operations (such as error handling) in response to a particular database error. This field is not localizable, and is always present.
Passed to pg_result_error_field(). The primary human-readable error message (typically one line). Always present.
Passed to pg_result_error_field(). Detail: an optional secondary error message carrying more detail about the problem. May run to multiple lines.
Passed to pg_result_error_field(). Hint: an optional suggestion what to do about the problem. This is intended to differ from detail in that it offers advice (potentially inappropriate) rather than hard facts. May run to multiple lines.
Passed to pg_result_error_field(). A string containing a decimal integer indicating an error cursor position as an index into the original statement string. The first character has index 1, and positions are measured in characters not bytes.
Passed to pg_result_error_field(). This is defined the same as the PG_DIAG_STATEMENT_POSITION field, but it is used when the cursor position refers to an internally generated command rather than the one submitted by the client. The PG_DIAG_INTERNAL_QUERY field will always appear when this field appears.
Passed to pg_result_error_field(). The text of a failed internally-generated command. This could be, for example, a SQL query issued by a PL/pgSQL function.
Passed to pg_result_error_field(). An indication of the context in which the error occurred. Presently this includes a call stack traceback of active procedural language functions and internally-generated queries. The trace is one entry per line, most recent first.
Passed to pg_result_error_field(). The file name of the PostgreSQL source-code location where the error was reported.
Passed to pg_result_error_field(). The line number of the PostgreSQL source-code location where the error was reported.
Passed to pg_result_error_field(). The name of the PostgreSQL source-code function reporting the error.
Passed to pg_set_error_verbosity(). Specified that returned messages include severity, primary text, and position only; this will normally fit on a single line.
Passed to pg_set_error_verbosity(). The default mode produces messages that include the above plus any detail, hint, or context fields (these may span multiple lines).
Passed to pg_set_error_verbosity(). The verbose mode includes all available fields.
Passed to pg_result_status(). Indicates that numerical result code is desired.
Passed to pg_result_status(). Indicates that textual result command tag is desired.
Passed to pg_convert(). Ignore default values in the table during conversion.
Passed to pg_convert(). Ignore conversion of NULL into SQL NOT NULL columns.
Starting with PostgreSQL 7.1.0, you can store up to 1GB into a field of type text. In older versions, this was limited to the block size (default was 8KB, maximum was 32KB, defined at compile time)
To use the large object (lo) interface, it is required to enclose large object functions within a transaction block. A transaction block starts with a SQL statement BEGIN and if the transaction was valid ends with COMMIT or END. If the transaction fails the transaction should be closed with ROLLBACK or ABORT.
Example 2. Using Large Objects
Hosting by: Hurra Communications Ltd.
Generated: 2007-01-26 18:00:29