libpq C++ Binding
- libpq++ is the C++ API to
- libpq++ is a set of classes which allow
- client programs to connect to the
-
Postgres backend server. These connections
- come in two forms: a Database Class and a Large Object class.
+ libpq++ is the C++ API to
+ libpq++ is a set of classes which allow
+ client programs to connect to the
+
Postgres backend server. These connections
+ come in two forms: a Database Class and a Large Object class.
+
- The Database Class is intended for manipulating a database. You can
-
send all sorts of SQL queries to the
Postgres
- backend server and retrieve the responses of the server.
+ The Database Class is intended for manipulating a database. You can
+ send all sorts of SQL queries to the
Postgres
+ backend server and retrieve the responses of the server.
+
- The Large Object Class is intended for manipulating a large object
- in a database. Although a Large Object instance can send normal
-
queries to the
Postgres backend server
- it is only intended for simple
- queries that do not return any data. A large object should be seen
- as a file stream. In the future it should behave much like the C++ file
- streams
- cin,
- cout
- and
- cerr.
+ The Large Object Class is intended for manipulating a large object
+ in a database. Although a Large Object instance can send normal
+ queries to the
Postgres backend server
+ it is only intended for simple
+ queries that do not return any data. A large object should be seen
+ as a file stream. In the future it should behave much like the C++ file
+ streams
+ cin,
+ cout
+ and
+ cerr.
+
- This chapter is based on the documentation
- for the libpq C library. Three
- short programs are listed at the end of this section as examples of
- libpq++ programming
- (though not necessarily of good programming).
- There are several examples of libpq++
- applications in
- src/libpq++/examples, including the source
- code for the three examples in this chapter.
+ This chapter is based on the documentation
+ for the libpq C library. Three
+ short programs are listed at the end of this section as examples of
+ libpq++ programming
+ (though not necessarily of good programming).
+ There are several examples of libpq++
+ applications in
+ src/libpq++/examples, including the source
+ code for the three examples in this chapter.
Environment Variables
-
- The following environment variables can be used to set up default
- values for an environment and to avoid hard-coding database names into
- an application program:
-
- Refer to the for a complete
- list of available connection options.
-
-
-
- The following environment variables can be used to select default
- connection parameter values, which will be used by PQconnectdb or
- PQsetdbLogin if no value is directly specified by the calling code.
- These are useful to avoid hard-coding database names into simple
- application programs.
-
- libpq++ uses only environment variables or PQconnectdb
- conninfo style strings.
-
-
-
-
-
- PGHOST sets the default server name.
- If a non-zero-length string is specified, TCP/IP communication is used.
- Without a host name, libpq will connect using a local Unix domain socket.
-
-
-
- PGPORT sets the default port or local Unix domain socket
- file extension for communicating with the
Postgres
- backend.
-
-
-
- PGDATABASE sets the default
-
Postgres database name.
-
-
-
- PGUSER
- sets the username used to connect to the database and for authentication.
-
-
-
- PGPASSWORD
- sets the password used if the backend demands password authentication.
-
-
-
- PGREALM sets the Kerberos realm to use with
- if it is different from the local realm. If
-
PGREALM is set,
Postgres
- applications will attempt
- authentication with servers for this realm and use
- separate ticket files to avoid conflicts with local
- ticket files. This environment variable is only
- used if Kerberos authentication is selected by the backend.
-
-
-
- PGOPTIONS sets additional runtime options for
-
-
-
- PGTTY sets the file or tty on which debugging
- messages from the backend server are displayed.
-
-
-
-
-
- The following environment variables can be used to specify user-level default
- behavior for every Postgres session:
+ The following environment variables can be used to set up default
+ values for an environment and to avoid hard-coding database names into
+ an application program:
+
+ Refer to the for a complete
+ list of available connection options.
+
+
+
+
+ The following environment variables can be used to select default
+ connection parameter values, which will be used by PQconnectdb or
+ PQsetdbLogin if no value is directly specified by the calling code.
+ These are useful to avoid hard-coding database names into simple
+ application programs.
+
+ libpq++ uses only environment variables or PQconnectdb
+ conninfo style strings.
+
+
-
-
- PGDATESTYLE
- sets the default style of date/time representation.
-
-
-
- PGTZ
- sets the default time zone.
-
-
-
-
+
+
+ PGHOST sets the default server name.
+ If a non-zero-length string is specified, TCP/IP communication is used.
+ Without a host name, libpq will connect using a local Unix domain socket.
+
+
+
+ PGPORT sets the default port or local Unix domain socket
+ file extension for communicating with the
Postgres
+ backend.
+
+
+
+ PGDATABASE sets the default
+
Postgres database name.
+
+
+
+ PGUSER
+ sets the username used to connect to the database and for authentication.
+
+
+
+ PGPASSWORD
+ sets the password used if the backend demands password authentication.
+
+
+
+ PGREALM sets the Kerberos realm to use with
+ if it is different from the local realm. If
+
PGREALM is set,
Postgres
+ applications will attempt
+ authentication with servers for this realm and use
+ separate ticket files to avoid conflicts with local
+ ticket files. This environment variable is only
+ used if Kerberos authentication is selected by the backend.
+
+
+
+ PGOPTIONS sets additional runtime options for
+
+
+
+ PGTTY sets the file or tty on which debugging
+ messages from the backend server are displayed.
+
+
+
+
- The following environment variables can be used to specify default internal
- behavior for every Postgres session:
+ The following environment variables can be used to specify user-level default
+ behavior for every Postgres session:
-
-
- PGGEQO
- sets the default mode for the genetic optimizer.
-
-
-
- PGRPLANS
- sets the default mode to allow or disable right-sided plans in the optimizer.
-
-
-
- PGCOSTHEAP
- sets the default cost for heap searches for the optimizer.
-
-
-
- PGCOSTINDEX
- sets the default cost for indexed searches for the optimizer.
-
-
-
- PGQUERY_LIMIT
- sets the maximum number of rows returned by a query.
-
-
-
-
+
+
+ PGDATESTYLE
+ sets the default style of date/time representation.
+
+
+
+ PGTZ
+ sets the default time zone.
+
+
+
+
+
+ The following environment variables can be used to specify default internal
+ behavior for every Postgres session:
+
+
+
+ PGGEQO
+ sets the default mode for the genetic optimizer.
+
+
+
+ PGRPLANS
+ sets the default mode to allow or disable right-sided plans in the optimizer.
+
+
+
+ PGCOSTHEAP
+ sets the default cost for heap searches for the optimizer.
+
+
+
+ PGCOSTINDEX
+ sets the default cost for indexed searches for the optimizer.
+
+
+
+ PGQUERY_LIMIT
+ sets the maximum number of rows returned by a query.
+
+
+
+
- Refer to the
SET SQL command
- for information on correct values for these environment variables.
-
-
-
-
-
libpq++ Classes
-
-
Connection Class: PgConnection
- The connection class makes the actual connection to the database and is inherited
- by all of the access classes.
-
-
-
-
Database Class: PgDatabase
- The database class provides C++ objects that have a connection
- to a backend server. To create such an object one first needs
- the apropriate environment for the backend to access.
- The following constructors deal with making a connection to a backend
- server from a C++ program.
-
-
+ Refer to the
SET SQL command
+ for information on correct values for these environment variables.
+
+
+
-
Database Connection Functions
+
libpq++ Classes
+
+
+
Connection Class: PgConnection
+
-
-
- PgConnection
- makes a new connection to a backend database server.
-
- PgConnection::PgConnection(const char *conninfo)
-
- Although typically called from one of the access classes, a connection to
- a backend server is possible by creating a PgConnection object.
-
-
-
- ConnectionBad
- returns whether or not the connection to the backend server succeeded or
- failed.
-
- int PgConnection::ConnectionBad()
-
- Returns TRUE if the connection failed.
-
-
-
- Status
- returns the status of the connection to the backend server.
-
- ConnStatusType PgConnection::Status()
-
- Returns either CONNECTION_OK or CONNECTION_BAD depending on the state
- of the connection.
-
-
-
- PgDatabase
- makes a new connection to a backend database server.
-
- PgDatabase(const char *conninfo)
-
- After a PgDatabase has been created it should be checked to make sure
- the connection to the database succeded before sending
- queries to the object. This can easily be done by
- retrieving the current status of the PgDatabase object with the
- Status or ConnectionBad methods.
-
-
-
- DBName
- Returns the name of the current database.
-
- const char *PgConnection::DBName()
-
-
-
-
- Notifies
- Returns the next notification from a list of unhandled notification messages
- received from the backend.
-
- PGnotify* PgConnection::Notifies()
-
- See PQnotifies() for details.
-
-
-
+ The connection class makes the actual connection to the database and is inherited
+ by all of the access classes.
+
+
+
+
Database Class: PgDatabase
+
+ The database class provides C++ objects that have a connection
+ to a backend server. To create such an object one first needs
+ the apropriate environment for the backend to access.
+ The following constructors deal with making a connection to a backend
+ server from a C++ program.
+
+
+
-
Query Execution Functions
-
-
- Exec
- Sends a query to the backend server. It's probably more desirable to
- use one of the next two functions.
-
- ExecStatusType PgConnection::Exec(const char* query)
-
- Returns the result of the query. The following status results can be expected:
-
-
-
- PGRES_EMPTY_QUERY
-
-
- PGRES_COMMAND_OK, if the query was a command
-
-
- PGRES_TUPLES_OK, if the query successfully returned tuples
-
-
- PGRES_COPY_OUT
-
-
- PGRES_COPY_IN
-
-
- PGRES_BAD_RESPONSE, if an unexpected response was received
-
-
- PGRES_NONFATAL_ERROR
-
-
- PGRES_FATAL_ERROR
-
-
-
-
-
- ExecCommandOk
- Sends a command query to the backend server.
-
- int PgConnection::ExecCommandOk(const char *query)
-
- Returns TRUE if the command query succeeds.
-
-
-
- ExecTuplesOk
- Sends a command query to the backend server.
-
- int PgConnection::ExecTuplesOk(const char *query)
-
- Returns TRUE if the command query succeeds and there are tuples to be retrieved.
-
-
-
- ErrorMessage
- Returns the last error message text.
-
- const char *PgConnection::ErrorMessage()
-
-
-
-
- Tuples
- Returns the number of tuples (instances) in the query result.
-
- int PgDatabase::Tuples()
-
-
-
-
- Fields
- Returns the number of fields (attributes) in each tuple of the query result.
-
- int PgDatabase::Fields()
-
-
-
-
- FieldName
- Returns the field (attribute) name associated with the given field index.
- Field indices start at 0.
-
- const char *PgDatabase::FieldName(int field_num)
-
-
-
-
- FieldNum
- PQfnumber Returns the field (attribute) index associated with
- the given field name.
-
- int PgDatabase::FieldNum(const char* field_name)
-
- -1 is returned if the given name does not match any field.
-
-
-
- FieldType
- Returns the field type associated with the given field index. The
- integer returned is an internal coding of the type. Field indices
- start at 0.
-
- Oid PgDatabase::FieldType(int field_num)
-
-
-
-
- FieldType
- Returns the field type associated with the given field name. The
- integer returned is an internal coding of the type. Field indices
- start at 0.
-
- Oid PgDatabase::FieldType(const char* field_name)
-
-
-
-
- FieldSize
- Returns the size in bytes of the field associated with the given
- field index. Field indices start at 0.
-
- short PgDatabase::FieldSize(int field_num)
-
- Returns the space allocated for this field in a database tuple given
- the field number. In other words the size of the server's binary
- representation of the data type. -1 is returned if the field is
- variable size.
-
-
-
- FieldSize
- Returns the size in bytes of the field associated with the given
- field index. Field indices start at 0.
-
- short PgDatabase::FieldSize(const char *field_name)
-
- Returns the space allocated for this field in a database tuple given
- the field name. In other words the size of the server's binary
- representation of the data type. -1 is returned if the field is
- variable size.
-
-
-
- GetValue
- Returns a single field (attribute) value of one tuple of a PGresult.
- Tuple and field indices start at 0.
-
- const char *PgDatabase::GetValue(int tup_num, int field_num)
-
- For most queries, the value returned by GetValue is a null-terminated
- ASCII string representation of the attribute value. But if BinaryTuples()
- is TRUE, the value returned by GetValue is the binary representation
- of the type in the internal format of the backend server (but not including
- the size word, if the field is variable-length). It is then the programmer's
- responsibility to cast and convert the data to the correct C type. The
- pointer returned by GetValue points to storage that is part of the
- PGresult structure. One should not modify it, and one must explicitly
- copy the value into other storage if it is to be used past the lifetime
- of the PGresult structure itself. BinaryTuples() is not yet implemented.
-
-
-
- GetValue
- Returns a single field (attribute) value of one tuple of a PGresult.
- Tuple and field indices start at 0.
-
- const char *PgDatabase::GetValue(int tup_num, const char *field_name)
-
- For most queries, the value returned by GetValue is a null-terminated
- ASCII string representation of the attribute value. But if BinaryTuples()
- is TRUE, the value returned by GetValue is the binary representation
- of the type in the internal format of the backend server (but not including
- the size word, if the field is variable-length). It is then the programmer's
- responsibility to cast and convert the data to the correct C type. The
- pointer returned by GetValue points to storage that is part of the
- PGresult structure. One should not modify it, and one must explicitly
- copy the value into other storage if it is to be used past the lifetime
- of the PGresult structure itself. BinaryTuples() is not yet implemented.
-
-
-
- GetLength
- Returns the length of a field (attribute) in bytes. Tuple and field
- indices start at 0.
-
- int PgDatabase::GetLength(int tup_num, int field_num)
-
- This is the actual data length for the particular data value, that
- is the size of the object pointed to by GetValue. Note that for
- ASCII-represented values, this size has little to do with the binary
- size reported by PQfsize.
-
-
-
- GetLength
- Returns the length of a field (attribute) in bytes. Tuple and field
- indices start at 0.
-
- int PgDatabase::GetLength(int tup_num, const char* field_name)
-
- This is the actual data length for the particular data value, that
- is the size of the object pointed to by GetValue. Note that for
- ASCII-represented values, this size has little to do with the binary
- size reported by PQfsize.
-
-
-
- DisplayTuples
- Prints out all the tuples and, optionally, the attribute names to the
- specified output stream.
-
- void PgDatabase::DisplayTuples(FILE *out = 0, int fillAlign = 1,
- const char* fieldSep = "|",int printHeader = 1, int quiet = 0)
-
-
-
-
- PrintTuples
- Prints out all the tuples and, optionally, the attribute names to the
- specified output stream.
-
- void PgDatabase::PrintTuples(FILE *out = 0, int printAttName = 1,
- int terseOutput = 0, int width = 0)
-
-
-
-
- GetLine
-
- int PgDatabase::GetLine(char* string, int length)
-
-
-
-
- PutLine
-
- void PgDatabase::PutLine(const char* string)
-
-
-
-
- OidStatus
-
- const char *PgDatabase::OidStatus()
-
-
-
-
- EndCopy
-
- int PgDatabase::EndCopy()
-
-
-
-
-
+
Database Connection Functions
+
+
+ PgConnection
+ makes a new connection to a backend database server.
+
+ PgConnection::PgConnection(const char *conninfo)
+
+ Although typically called from one of the access classes, a connection to
+ a backend server is possible by creating a PgConnection object.
+
+
+
+ ConnectionBad
+ returns whether or not the connection to the backend server succeeded or
+ failed.
+
+ int PgConnection::ConnectionBad()
+
+ Returns TRUE if the connection failed.
+
+
+
+ Status
+ returns the status of the connection to the backend server.
+
+ ConnStatusType PgConnection::Status()
+
+ Returns either CONNECTION_OK or CONNECTION_BAD depending on the state
+ of the connection.
+
+
+
+ PgDatabase
+ makes a new connection to a backend database server.
+
+ PgDatabase(const char *conninfo)
+
+ After a PgDatabase has been created it should be checked to make sure
+ the connection to the database succeded before sending
+ queries to the object. This can easily be done by
+ retrieving the current status of the PgDatabase object with the
+ Status or ConnectionBad methods.
+
+
+
+ DBName
+ Returns the name of the current database.
+
+ const char *PgConnection::DBName()
+
+
+
+
+ Notifies
+ Returns the next notification from a list of unhandled notification messages
+ received from the backend.
+
+ PGnotify* PgConnection::Notifies()
+
+ See PQnotifies() for details.
+
+
+
+
+
-
Asynchronous Notification
+
Query Execution Functions
+
+
+ Exec
+ Sends a query to the backend server. It's probably more desirable to
+ use one of the next two functions.
+
+ ExecStatusType PgConnection::Exec(const char* query)
+
+ Returns the result of the query. The following status results can be expected:
+
+
+
+ PGRES_EMPTY_QUERY
+
+
+ PGRES_COMMAND_OK, if the query was a command
+
+
+ PGRES_TUPLES_OK, if the query successfully returned tuples
+
+
+ PGRES_COPY_OUT
+
+
+ PGRES_COPY_IN
+
+
+ PGRES_BAD_RESPONSE, if an unexpected response was received
+
+
+ PGRES_NONFATAL_ERROR
+
+
+ PGRES_FATAL_ERROR
+
+
+
+
+
+ ExecCommandOk
+ Sends a command query to the backend server.
+
+ int PgConnection::ExecCommandOk(const char *query)
+
+ Returns TRUE if the command query succeeds.
+
+
+
+ ExecTuplesOk
+ Sends a command query to the backend server.
+
+ int PgConnection::ExecTuplesOk(const char *query)
+
+ Returns TRUE if the command query succeeds and there are tuples to be retrieved.
+
+
+
+ ErrorMessage
+ Returns the last error message text.
+
+ const char *PgConnection::ErrorMessage()
+
+
+
+
+ Tuples
+ Returns the number of tuples (instances) in the query result.
+
+ int PgDatabase::Tuples()
+
+
+
+
+ Fields
+ Returns the number of fields (attributes) in each tuple of the query result.
+
+ int PgDatabase::Fields()
+
+
+
+
+ FieldName
+ Returns the field (attribute) name associated with the given field index.
+ Field indices start at 0.
+
+ const char *PgDatabase::FieldName(int field_num)
+
+
+
+
+ FieldNum
+ PQfnumber Returns the field (attribute) index associated with
+ the given field name.
+
+ int PgDatabase::FieldNum(const char* field_name)
+
+ -1 is returned if the given name does not match any field.
+
+
+
+ FieldType
+ Returns the field type associated with the given field index. The
+ integer returned is an internal coding of the type. Field indices
+ start at 0.
+
+ Oid PgDatabase::FieldType(int field_num)
+
+
+
+
+ FieldType
+ Returns the field type associated with the given field name. The
+ integer returned is an internal coding of the type. Field indices
+ start at 0.
+
+ Oid PgDatabase::FieldType(const char* field_name)
+
+
+
+
+ FieldSize
+ Returns the size in bytes of the field associated with the given
+ field index. Field indices start at 0.
+
+ short PgDatabase::FieldSize(int field_num)
+
+ Returns the space allocated for this field in a database tuple given
+ the field number. In other words the size of the server's binary
+ representation of the data type. -1 is returned if the field is
+ variable size.
+
+
+
+ FieldSize
+ Returns the size in bytes of the field associated with the given
+ field index. Field indices start at 0.
+
+ short PgDatabase::FieldSize(const char *field_name)
+
+ Returns the space allocated for this field in a database tuple given
+ the field name. In other words the size of the server's binary
+ representation of the data type. -1 is returned if the field is
+ variable size.
+
+
+
+ GetValue
+ Returns a single field (attribute) value of one tuple of a PGresult.
+ Tuple and field indices start at 0.
+
+ const char *PgDatabase::GetValue(int tup_num, int field_num)
+
+ For most queries, the value returned by GetValue is a null-terminated
+ ASCII string representation of the attribute value. But if BinaryTuples()
+ is TRUE, the value returned by GetValue is the binary representation
+ of the type in the internal format of the backend server (but not including
+ the size word, if the field is variable-length). It is then the programmer's
+ responsibility to cast and convert the data to the correct C type. The
+ pointer returned by GetValue points to storage that is part of the
+ PGresult structure. One should not modify it, and one must explicitly
+ copy the value into other storage if it is to be used past the lifetime
+ of the PGresult structure itself. BinaryTuples() is not yet implemented.
+
+
+
+ GetValue
+ Returns a single field (attribute) value of one tuple of a PGresult.
+ Tuple and field indices start at 0.
+
+ const char *PgDatabase::GetValue(int tup_num, const char *field_name)
+
+ For most queries, the value returned by GetValue is a null-terminated
+ ASCII string representation of the attribute value. But if BinaryTuples()
+ is TRUE, the value returned by GetValue is the binary representation
+ of the type in the internal format of the backend server (but not including
+ the size word, if the field is variable-length). It is then the programmer's
+ responsibility to cast and convert the data to the correct C type. The
+ pointer returned by GetValue points to storage that is part of the
+ PGresult structure. One should not modify it, and one must explicitly
+ copy the value into other storage if it is to be used past the lifetime
+ of the PGresult structure itself. BinaryTuples() is not yet implemented.
+
+
+
+ GetLength
+ Returns the length of a field (attribute) in bytes. Tuple and field
+ indices start at 0.
+
+ int PgDatabase::GetLength(int tup_num, int field_num)
+
+ This is the actual data length for the particular data value, that
+ is the size of the object pointed to by GetValue. Note that for
+ ASCII-represented values, this size has little to do with the binary
+ size reported by PQfsize.
+
+
+
+ GetLength
+ Returns the length of a field (attribute) in bytes. Tuple and field
+ indices start at 0.
+
+ int PgDatabase::GetLength(int tup_num, const char* field_name)
+
+ This is the actual data length for the particular data value, that
+ is the size of the object pointed to by GetValue. Note that for
+ ASCII-represented values, this size has little to do with the binary
+ size reported by PQfsize.
+
+
+
+ DisplayTuples
+ Prints out all the tuples and, optionally, the attribute names to the
+ specified output stream.
+
+ void PgDatabase::DisplayTuples(FILE *out = 0, int fillAlign = 1,
+ const char* fieldSep = "|",int printHeader = 1, int quiet = 0)
+
+
+
+
+ PrintTuples
+ Prints out all the tuples and, optionally, the attribute names to the
+ specified output stream.
+
+ void PgDatabase::PrintTuples(FILE *out = 0, int printAttName = 1,
+ int terseOutput = 0, int width = 0)
+
+
+
+
+ GetLine
+
+ int PgDatabase::GetLine(char* string, int length)
+
+
+
+
+ PutLine
+
+ void PgDatabase::PutLine(const char* string)
+
+
+
+
+ OidStatus
+
+ const char *PgDatabase::OidStatus()
+
+
+
+
+ EndCopy
+
+ int PgDatabase::EndCopy()
+
+
+
+
+
+
+
+
+
Asynchronous Notification
-
Postgres supports asynchronous notification
- via the LISTEN and NOTIFY
- commands. A backend registers its interest in a particular semaphore
- with the LISTEN command.
- All backends that are listening on a
- particular named semaphore will be notified asynchronously when
- a NOTIFY of
- that name is executed by another backend. No additional
- information is passed from the notifier to the listener. Thus,
- typically, any actual data that needs to be communicated is transferred
- through the relation.
-
-
- In the past, the documentation has associated the names used for asyncronous
- notification with relations or classes. However, there is in fact no
- direct linkage of the two concepts in the implementation, and the
- named semaphore in fact does not need to have a corresponding relation
- previously defined.
-
-
-
- libpq++ applications are notified whenever a
- connected backend has
- received an asynchronous notification. However, the communication from
- the backend to the frontend is not asynchronous.
- The libpq++ application
- must poll the backend to see if there is any pending notification
- information. After the execution of a query, a frontend may call
- PgDatabase::Notifies
- to see if any notification data is currently available from the backend.
- PgDatabase::Notifies
- returns the notification from a list of unhandled notifications from the
- backend. The function eturns NULL if there is no pending notifications from the
- backend.
- PgDatabase::Notifies
- behaves like the popping of a stack. Once a notification is returned
- from PgDatabase::Notifies,
- it is considered handled and will be removed from the list of
- notifications.
-
-
-
- PgDatabase::Notifies
- retrieves pending notifications from the server.
-
-
- PGnotify* PgDatabase::Notifies()
-
-
-
-
-
- The second sample program gives an example of the use of asynchronous
- notification.
-
+
Postgres supports asynchronous notification
+ via the LISTEN and NOTIFY
+ commands. A backend registers its interest in a particular semaphore
+ with the LISTEN command.
+ All backends that are listening on a
+ particular named semaphore will be notified asynchronously when
+ a NOTIFY of
+ that name is executed by another backend. No additional
+ information is passed from the notifier to the listener. Thus,
+ typically, any actual data that needs to be communicated is transferred
+ through the relation.
+
+
+ In the past, the documentation has associated the names used for asyncronous
+ notification with relations or classes. However, there is in fact no
+ direct linkage of the two concepts in the implementation, and the
+ named semaphore in fact does not need to have a corresponding relation
+ previously defined.
+
+
+
+ libpq++ applications are notified whenever a
+ connected backend has
+ received an asynchronous notification. However, the communication from
+ the backend to the frontend is not asynchronous.
+ The libpq++ application
+ must poll the backend to see if there is any pending notification
+ information. After the execution of a query, a frontend may call
+ PgDatabase::Notifies
+ to see if any notification data is currently available from the backend.
+ PgDatabase::Notifies
+ returns the notification from a list of unhandled notifications from the
+ backend. The function eturns NULL if there is no pending notifications from the
+ backend.
+ PgDatabase::Notifies
+ behaves like the popping of a stack. Once a notification is returned
+ from PgDatabase::Notifies,
+ it is considered handled and will be removed from the list of
+ notifications.
+
+
+
+ PgDatabase::Notifies
+ retrieves pending notifications from the server.
+
+
+ PGnotify* PgDatabase::Notifies()
+
+
+
+
+
+ The second sample program gives an example of the use of asynchronous
+ notification.
+
+
-
Functions Associated with the COPY Command
+
Functions Associated with the COPY Command
+
+ The
copy command in
Postgres
+ has options to read from or write to the network
+ connection used by libpq++.
+ Therefore, functions are necessary to
+ access this network connection directly so applications may take full
+ advantage of this capability.
- The
copy command in
Postgres
- has options to read from or write to the network
- connection used by libpq++.
- Therefore, functions are necessary to
- access this network connection directly so applications may take full
- advantage of this capability.
-
-
-
- PgDatabase::GetLine
- reads a newline-terminated line of characters (transmitted by the
- backend server) into a buffer
- string
- of size length.
-
- int PgDatabase::GetLine(char* string, int length)
-
-
- Like the Unix system routine
- fgets (3),
- this routine copies up to
- length-1
- characters into
- string.
- It is like
- gets (3),
- however, in that it converts the terminating newline into a null
- character.
-
- PgDatabase::GetLine
- returns EOF at end of file, 0 if the entire line has been read, and 1 if the
- buffer is full but the terminating newline has not yet been read.
-
- Notice that the application must check to see if a new line consists
- of a single period ("."), which indicates that the backend
- server has finished sending the results of the
- copy.
- Therefore, if the application ever expects to receive lines
- that are more than
- length-1
- characters long, the application must be sure to check the return
- value of PgDatabase::GetLine very carefully.
-
-
-
- PgDatabase::PutLine
- Sends a null-terminated string
- to the backend server.
-
- void PgDatabase::PutLine(char* string)
-
-
- The application must explicitly send a single period character (".")
- to indicate to the backend that it has finished sending its data.
-
-
-
- PgDatabase::EndCopy
- syncs with the backend.
-
- int PgDatabase::EndCopy()
-
- This function waits until the backend has
- finished processing the copy.
- It should either be issued when the
- last string has been sent to the backend using
- PgDatabase::PutLine
- or when the last string has been received from the backend using
- PgDatabase::GetLine.
- It must be issued or the backend may get out of sync
with
- the frontend. Upon return from this function, the backend is ready to
- receive the next query.
-
- The return value is 0 on successful completion, nonzero otherwise.
-
-
-
-
- As an example:
-
+
+
+ PgDatabase::GetLine
+ reads a newline-terminated line of characters (transmitted by the
+ backend server) into a buffer
+ string
+ of size length.
+
+ int PgDatabase::GetLine(char* string, int length)
+
+
+ Like the Unix system routine
+ fgets (3),
+ this routine copies up to
+ length-1
+ characters into
+ string.
+ It is like
+ gets (3),
+ however, in that it converts the terminating newline into a null
+ character.
+
+ PgDatabase::GetLine
+ returns EOF at end of file, 0 if the entire line has been read, and 1 if the
+ buffer is full but the terminating newline has not yet been read.
+
+ Notice that the application must check to see if a new line consists
+ of a single period ("."), which indicates that the backend
+ server has finished sending the results of the
+ copy.
+ Therefore, if the application ever expects to receive lines
+ that are more than
+ length-1
+ characters long, the application must be sure to check the return
+ value of PgDatabase::GetLine very carefully.
+
+
+
+ PgDatabase::PutLine
+ Sends a null-terminated string
+ to the backend server.
+
+ void PgDatabase::PutLine(char* string)
+
+
+ The application must explicitly send a single period character (".")
+ to indicate to the backend that it has finished sending its data.
+
+
+
+ PgDatabase::EndCopy
+ syncs with the backend.
+
+ int PgDatabase::EndCopy()
+
+ This function waits until the backend has
+ finished processing the copy.
+ It should either be issued when the
+ last string has been sent to the backend using
+ PgDatabase::PutLine
+ or when the last string has been received from the backend using
+ PgDatabase::GetLine.
+ It must be issued or the backend may get out of sync
with
+ the frontend. Upon return from this function, the backend is ready to
+ receive the next query.
+
+ The return value is 0 on successful completion, nonzero otherwise.
+
+
+
+
+ As an example:
+
PgDatabase data;
data.exec("create table foo (a int4, b char16, d float8)");
data.exec("copy foo from stdin");
data.putline("3\etHello World\et4.5\en");
data.putline("4\etGoodbye World\et7.11\en");
- \&...
+ &...
data.putline(".\en");
data.endcopy();
-
-
-
+
+
+
-
Caveats
+
Caveats
- The query buffer is 8192 bytes long, and queries over that length will
- be silently truncated.
-
+ The query buffer is 8192 bytes long, and queries over that length will
+ be silently truncated.
+
-This release marks the development team's final mastery of the source
-code we inherited from Berkeley. You will see we are now easily adding
-major features, thanks to the increasing size and experience of our
-world-wide development team: Here is a brief, incomplete summary:
-
-
-
-Multi-version concurrency control(MVCC): This removes our old
-table-level locking, and replaces it with a locking system that is
-superior to most commercial database systems. In a traditional system,
-each row that is modified is locked until committed, preventing reads by
-other users. MVCC uses the natural multi-version nature of PostgreSQL
-to allow readers to continue reading consistent data during writer
-activity. Writers continue to use the compact pg_log transaction
-system. This is all preformed without having to allocate a lock for
-every row like traditional database systems. So, basically, we no
-longer have table-level locking, we have something better than row-level
-locking.
-
-
-
-Numeric data type: We now have a true numeric data type, with
-user-specified precision.
-
-
-
-
-Temporary tables: Temporary tables are guaranteed to have unique names
-within a database session, and are destroyed on session exit.
-
-
-
-
-New SQL features: We now have CASE, INTERSECT, and EXCEPT statement
-support. We have new LIMIT/OFFSET, SET TRANSACTION ISOLATION LEVEL,
-SELECT ... FOR UPDATE, and an improved LOCK command.
-
-
-
-
-Speedups: We continue to speed up PostgreSQL, thanks to the variety of
-talents within our team. We have sped up memory allocation,
-optimization, table joins, and row transfers routines.
-
-
-
-
-Other: We continue to expand our port list, this time including
-Win32/NT. Most interfaces have new versions, and existing functionality
-has been improved.
-
-
-
-
-
-
-
-
Migration to v6.5
-
-A dump/restore using
pg_dump
-is required for those wishing to migrate data from any
-previous release of
Postgres.
-
-
-
-
Detailed Change List
-
+ This release marks a major step in the development team's mastery of the source
+ code we inherited from Berkeley. You will see we are now easily adding
+ major features, thanks to the increasing size and experience of our
+ world-wide development team.
+
+
+ Here is a brief summary of some of the more noticable changes:
+
+
+
+
+ Multi-version concurrency control(MVCC)
+
+
+ This removes our old
+ table-level locking, and replaces it with a locking system that is
+ superior to most commercial database systems. In a traditional system,
+ each row that is modified is locked until committed, preventing reads by
+ other users. MVCC uses the natural multi-version nature of PostgreSQL
+ to allow readers to continue reading consistent data during writer
+ activity. Writers continue to use the compact pg_log transaction
+ system. This is all preformed without having to allocate a lock for
+ every row like traditional database systems. So, basically, we no
+ longer have table-level locking, we have something better than row-level
+ locking.
+
+
+
+
+
+
+ Numeric data type
+
+
+ We now have a true numeric data type, with
+ user-specified precision.
+
+
+
+
+
+
+ Temporary tables
+
+
+ Temporary tables are guaranteed to have unique names
+ within a database session, and are destroyed on session exit.
+
+
+
+
+
+
+ New SQL features
+
+
+ We now have CASE, INTERSECT, and EXCEPT statement
+ support. We have new LIMIT/OFFSET, SET TRANSACTION ISOLATION LEVEL,
+ SELECT ... FOR UPDATE, and an improved LOCK command.
+
+
+
+
+
+
+ Speedups
+
+
+ We continue to speed up PostgreSQL, thanks to the variety of
+ talents within our team. We have sped up memory allocation,
+ optimization, table joins, and row transfer routines.
+
+
+
+
+
+
+ Ports
+
+
+ We continue to expand our port list, this time including
+ WinNT/ix86 and NetBSD/arm32.
+
+
+
+
+
+
+ Interfaces
+
+
+ Most interfaces have new versions, and existing functionality
+ has been improved.
+
+
+
+
+
+
+
+
Migration to v6.5
+
+ A dump/restore using
pg_dump
+ is required for those wishing to migrate data from any
+ previous release of
Postgres.
+
+
+
+
+
Detailed Change List
+
Bug Fixes
---------
Fix text<->float8 and text<->float4 conversion functions(Thomas)
Better support for HPUX 11 and Unixware
Improve file handling to be more uniform, prevent file descriptor leak(Tom)
New install commands for plpgsql(Jan)
-
-ara>
-
-ect1>
+
+ ara>
+
+ ect1>
-<Sect1>
-<Title>Release 6.4.2itle>
+<sect1>
+<title>Release 6.4.2itle>
-<Para>
+<para>
The regression tests have been adapted and extensively modified for the
v6.1 release of
Postgres.
-Para>
+para>
-<Para>
+<para>
Three new data types (datetime, timespan, and circle) have been added to
the native set of
Postgres types. Points, boxes, paths, and polygons
have had their output formats made consistant across the data types.
The polygon output in misc.out has only been spot-checked for correctness
relative to the original regression output.
-Para>
+para>
-
Postgres v6.1 introduces a new, alternate optimizer which uses
genetic
+
Postgres v6.1 introduces a new, alternate
+optimizer which uses genetic
algorithms. These algorithms introduce a random behavior in the ordering
of query results when the query contains multiple qualifiers or multiple
tables (giving the optimizer a choice on order of evaluation). Several
hence are insensitive to optimizer choices. A few regression tests are
for data types which are inherently unordered (e.g. points and time
intervals) and tests involving those types are explicitly bracketed with
- <Command>set geqo to 'off' and reset geqoommand>.
-Para>
+ <command>set geqo to 'off' and reset geqoommand>.
+para>
-<Para>
+<para>
The interpretation of array specifiers (the curly braces around atomic
values) appears to have changed sometime after the original regression
- tests were generated. The current <FileName>./expected/*.outame> files reflect this
+ tests were generated. The current <filename>./expected/*.outame> files reflect this
new interpretation, which may not be correct!
-Para>
+para>
-<Para>
+<para>
The float8 regression test fails on at least some platforms. This is due
to differences in implementations of pow() and exp() and the signaling
mechanisms used for overflow and underflow conditions.
-Para>
+para>
-<Para>
+<para>
The "random" results in the random test should cause the "random" test
to be "failed", since the regression tests are evaluated using a simple
diff. However, "random" does not seem to produce random results on my
test machine (Linux/gcc/i686).
-Para>
+para>
Migration to v6.1
-<Sect1>
-<Title>Timing Resultsitle>
+<sect1>
+<title>Timing Resultsitle>
-<Para>
+<para>
These timing results are from running the regression test with the commands
-<ProgramListing>
+<programlisting>
% cd src/test/regress
% make all
% time make runtest
-ProgramListing>
+programlisting>
-<Para>
+<para>
Timing under Linux 2.0.27 seems to have a roughly 5% variation from run
to run, presumably due to the scheduling vagaries of multitasking systems.
-<Sect2>
-<Title>v6.4betaitle>
+<sect2>
+<title>v6.4betaitle>
The times for this release are not directly comparable to those for previous releases
since some additional regression tests have been included.
In general, however, v6.4 should be slightly faster than the previous release (thanks, Bruce!).
-<Para>
-<ProgramListing>
+<para>
+<programlisting>
Time System
02:26 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
-ProgramListing>
+programlisting>
-<Sect2>
-<Title>v6.3itle>
+<sect2>
+<title>v6.3itle>
The times for this release are not directly comparable to those for previous releases
time travel have been removed.
In general, however, v6.3 is substantially faster than previous releases (thanks, Bruce!).
-<Para>
-<ProgramListing>
+<para>
+<programlisting>
Time System
02:30 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
04:12 Dual Pentium Pro 180, 96MB, EIDE, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486
-ProgramListing>
+programlisting>
-<Sect2>
-<Title>v6.1itle>
+<sect2>
+<title>v6.1itle>
-<Para>
-<ProgramListing>
+<para>
+<programlisting>
Time System
06:12 Pentium Pro 180, 32MB, EIDE, Linux 2.0.30, gcc 2.7.2 -O2 -m486
12:06 P-100, 48MB, Linux 2.0.29, gcc
39:58 Sparc IPC 32MB, Solaris 2.5, gcc 2.7.2.1 -O -g
-ProgramListing>
+programlisting>
-
+
+
+