<title>libpq C++ Binding</title>
<para>
- <filename>libpq++</filename> is the C++ API to
-
<productname>Postgres</productname>.
- <filename>libpq++</filename> is a set of classes which allow
- client programs to connect to the
-
<productname>Postgres</productname> backend server. These connections
- come in two forms: a Database Class and a Large Object class.
+ <filename>libpq++</filename> is the C++ API to
+ <productname>Postgres</productname>.
+ <filename>libpq++</filename> is a set of classes which allow
+ client programs to connect to the
+ <productname>Postgres</productname> backend server. These connections
+ come in two forms: a Database Class and a Large Object class.
</para>
+
<para>
- The Database Class is intended for manipulating a database. You can
-
send all sorts of SQL queries to the <productname>Postgres</productname>
- 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 <productname>Postgres</productname>
+ backend server and retrieve the responses of the server.
</para>
+
<para>
- 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 <productname>Postgres</productname> 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
- <literal>cin</literal>,
- <literal>cout</literal>
- and
- <literal>cerr</literal>.
+ 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 <productname>Postgres</productname> 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
+ <literal>cin</literal>,
+ <literal>cout</literal>
+ and
+ <literal>cerr</literal>.
</para>
+
<para>
- This chapter is based on the documentation
- for the <filename>libpq</filename> C library. Three
- short programs are listed at the end of this section as examples of
- <filename>libpq++</filename> programming
- (though not necessarily of good programming).
- There are several examples of <filename>libpq++</filename>
- applications in
- <filename>src/libpq++/examples</filename>, including the source
- code for the three examples in this chapter.
+ This chapter is based on the documentation
+ for the <filename>libpq</filename> C library. Three
+ short programs are listed at the end of this section as examples of
+ <filename>libpq++</filename> programming
+ (though not necessarily of good programming).
+ There are several examples of <filename>libpq++</filename>
+ applications in
+ <filename>src/libpq++/examples</filename>, including the source
+ code for the three examples in this chapter.
</para>
<sect1>
<sect2>
<title>Environment Variables</title>
-
- <para>
- 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:
- <note>
- <para>
- Refer to the <xref endterm="libpq" linkend="libpq-envars"> for a complete
- list of available connection options.
- </para>
- </note>
- </para>
- <para>
- 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.
- <note>
- <para>
- <filename>libpq++</filename> uses only environment variables or PQconnectdb
- conninfo style strings.
- </para>
- </note>
-
- <itemizedlist>
- <listitem>
- <para>
- <envar>PGHOST</envar> 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGPORT</envar> sets the default port or local Unix domain socket
- file extension for communicating with the <productname>Postgres</productname>
- backend.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGDATABASE</envar> sets the default
- <productname>Postgres</productname> database name.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGUSER</envar>
- sets the username used to connect to the database and for authentication.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGPASSWORD</envar>
- sets the password used if the backend demands password authentication.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGREALM</envar> sets the Kerberos realm to use with
- <productname>Postgres</productname>,
- if it is different from the local realm. If
- <envar>PGREALM</envar> is set, <productname>Postgres</productname>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGOPTIONS</envar> sets additional runtime options for
- the <productname>Postgres</productname> backend.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGTTY</envar> sets the file or tty on which debugging
- messages from the backend server are displayed.
- </para>
- </listitem>
- </itemizedlist>
- </para>
-
- <para>
- The following environment variables can be used to specify user-level default
- behavior for every Postgres session:
+ <para>
+ 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:
+ <note>
+ <para>
+ Refer to the <xref endterm="libpq" linkend="libpq-envars"> for a complete
+ list of available connection options.
+ </para>
+ </note>
+ </para>
+
+ <para>
+ 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.
+ <note>
+ <para>
+ <filename>libpq++</filename> uses only environment variables or PQconnectdb
+ conninfo style strings.
+ </para>
+ </note>
- <itemizedlist>
- <listitem>
- <para>
- <envar>PGDATESTYLE</envar>
- sets the default style of date/time representation.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGTZ</envar>
- sets the default time zone.
- </para>
- </listitem>
- </itemizedlist>
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <envar>PGHOST</envar> 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGPORT</envar> sets the default port or local Unix domain socket
+ file extension for communicating with the <productname>Postgres</productname>
+ backend.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGDATABASE</envar> sets the default
+ <productname>Postgres</productname> database name.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGUSER</envar>
+ sets the username used to connect to the database and for authentication.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGPASSWORD</envar>
+ sets the password used if the backend demands password authentication.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGREALM</envar> sets the Kerberos realm to use with
+ <productname>Postgres</productname>,
+ if it is different from the local realm. If
+ <envar>PGREALM</envar> is set, <productname>Postgres</productname>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGOPTIONS</envar> sets additional runtime options for
+ the <productname>Postgres</productname> backend.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGTTY</envar> sets the file or tty on which debugging
+ messages from the backend server are displayed.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
- The following environment variables can be used to specify default internal
- behavior for every Postgres session:
+ <para>
+ The following environment variables can be used to specify user-level default
+ behavior for every Postgres session:
- <itemizedlist>
- <listitem>
- <para>
- <envar>PGGEQO</envar>
- sets the default mode for the genetic optimizer.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGRPLANS</envar>
- sets the default mode to allow or disable right-sided plans in the optimizer.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGCOSTHEAP</envar>
- sets the default cost for heap searches for the optimizer.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGCOSTINDEX</envar>
- sets the default cost for indexed searches for the optimizer.
- </para>
- </listitem>
- <listitem>
- <para>
- <envar>PGQUERY_LIMIT</envar>
- sets the maximum number of rows returned by a query.
- </para>
- </listitem>
- </itemizedlist>
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <envar>PGDATESTYLE</envar>
+ sets the default style of date/time representation.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGTZ</envar>
+ sets the default time zone.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The following environment variables can be used to specify default internal
+ behavior for every Postgres session:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <envar>PGGEQO</envar>
+ sets the default mode for the genetic optimizer.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGRPLANS</envar>
+ sets the default mode to allow or disable right-sided plans in the optimizer.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGCOSTHEAP</envar>
+ sets the default cost for heap searches for the optimizer.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGCOSTINDEX</envar>
+ sets the default cost for indexed searches for the optimizer.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <envar>PGQUERY_LIMIT</envar>
+ sets the maximum number of rows returned by a query.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
- <para>
- Refer to the <command>SET</command> <acronym>SQL</acronym> command
- for information on correct values for these environment variables.
- </para>
- </sect2>
- </sect1>
- <sect1>
- <title>libpq++ Classes</title>
- <para></para>
- <sect2>
- <title>Connection Class: <classname>PgConnection</classname></title>
- <para>
- The connection class makes the actual connection to the database and is inherited
- by all of the access classes.
- </para>
- </sect2>
- <sect2>
- <title>Database Class: <classname>PgDatabase</classname></title>
- <para>
- 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.
- </para>
- </sect2>
+ <para>
+ Refer to the <command>SET</command> <acronym>SQL</acronym> command
+ for information on correct values for these environment variables.
+ </para>
+ </sect2>
</sect1>
+
<sect1>
- <title>Database Connection Functions</title>
+ <title>libpq++ Classes</title>
+
+ <sect2>
+ <title>Connection Class: <classname>PgConnection</classname></title>
+
<para>
- <itemizedlist>
- <listitem>
- <para>
- <function>PgConnection</function>
- makes a new connection to a backend database server.
- <synopsis>
- PgConnection::PgConnection(const char *conninfo)
- </synopsis>
- Although typically called from one of the access classes, a connection to
- a backend server is possible by creating a PgConnection object.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>ConnectionBad</function>
- returns whether or not the connection to the backend server succeeded or
- failed.
- <synopsis>
- int PgConnection::ConnectionBad()
- </synopsis>
- Returns TRUE if the connection failed.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>Status</function>
- returns the status of the connection to the backend server.
- <synopsis>
- ConnStatusType PgConnection::Status()
- </synopsis>
- Returns either CONNECTION_OK or CONNECTION_BAD depending on the state
- of the connection.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>PgDatabase</function>
- makes a new connection to a backend database server.
- <synopsis>
- PgDatabase(const char *conninfo)
- </synopsis>
- 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
- <function>Status</function> or <function>ConnectionBad</function> methods.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>DBName</function>
- Returns the name of the current database.
- <synopsis>
- const char *PgConnection::DBName()
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>Notifies</function>
- Returns the next notification from a list of unhandled notification messages
- received from the backend.
- <synopsis>
- PGnotify* PgConnection::Notifies()
- </synopsis>
- See PQnotifies() for details.
- </para>
- </listitem>
- </itemizedlist>
+ The connection class makes the actual connection to the database and is inherited
+ by all of the access classes.
</para>
+ </sect2>
+
+ <sect2>
+ <title>Database Class: <classname>PgDatabase</classname></title>
+
+ <para>
+ 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.
+ </para>
+ </sect2>
</sect1>
+
<sect1>
- <title>Query Execution Functions</title>
- <para>
- <itemizedlist>
- <listitem>
- <para>
- <function>Exec</function>
- Sends a query to the backend server. It's probably more desirable to
- use one of the next two functions.
- <synopsis>
- ExecStatusType PgConnection::Exec(const char* query)
- </synopsis>
- Returns the result of the query. The following status results can be expected:
-
- <simplelist>
- <member>
- PGRES_EMPTY_QUERY
- </member>
- <member>
- PGRES_COMMAND_OK, if the query was a command
- </member>
- <member>
- PGRES_TUPLES_OK, if the query successfully returned tuples
- </member>
- <member>
- PGRES_COPY_OUT
- </member>
- <member>
- PGRES_COPY_IN
- </member>
- <member>
- PGRES_BAD_RESPONSE, if an unexpected response was received
- </member>
- <member>
- PGRES_NONFATAL_ERROR
- </member>
- <member>
- PGRES_FATAL_ERROR
- </member>
- </simplelist>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>ExecCommandOk</function>
- Sends a command query to the backend server.
- <synopsis>
- int PgConnection::ExecCommandOk(const char *query)
- </synopsis>
- Returns TRUE if the command query succeeds.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>ExecTuplesOk</function>
- Sends a command query to the backend server.
- <synopsis>
- int PgConnection::ExecTuplesOk(const char *query)
- </synopsis>
- Returns TRUE if the command query succeeds and there are tuples to be retrieved.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>ErrorMessage</function>
- Returns the last error message text.
- <synopsis>
- const char *PgConnection::ErrorMessage()
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>Tuples</function>
- Returns the number of tuples (instances) in the query result.
- <synopsis>
- int PgDatabase::Tuples()
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>Fields</function>
- Returns the number of fields (attributes) in each tuple of the query result.
- <synopsis>
- int PgDatabase::Fields()
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>FieldName</function>
- Returns the field (attribute) name associated with the given field index.
- Field indices start at 0.
- <synopsis>
- const char *PgDatabase::FieldName(int field_num)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>FieldNum</function>
- PQfnumber Returns the field (attribute) index associated with
- the given field name.
- <synopsis>
- int PgDatabase::FieldNum(const char* field_name)
- </synopsis>
- -1 is returned if the given name does not match any field.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>FieldType</function>
- 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.
- <synopsis>
- Oid PgDatabase::FieldType(int field_num)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>FieldType</function>
- 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.
- <synopsis>
- Oid PgDatabase::FieldType(const char* field_name)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>FieldSize</function>
- Returns the size in bytes of the field associated with the given
- field index. Field indices start at 0.
- <synopsis>
- short PgDatabase::FieldSize(int field_num)
- </synopsis>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>FieldSize</function>
- Returns the size in bytes of the field associated with the given
- field index. Field indices start at 0.
- <synopsis>
- short PgDatabase::FieldSize(const char *field_name)
- </synopsis>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>GetValue</function>
- Returns a single field (attribute) value of one tuple of a PGresult.
- Tuple and field indices start at 0.
- <synopsis>
- const char *PgDatabase::GetValue(int tup_num, int field_num)
- </synopsis>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>GetValue</function>
- Returns a single field (attribute) value of one tuple of a PGresult.
- Tuple and field indices start at 0.
- <synopsis>
- const char *PgDatabase::GetValue(int tup_num, const char *field_name)
- </synopsis>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>GetLength</function>
- Returns the length of a field (attribute) in bytes. Tuple and field
- indices start at 0.
- <synopsis>
- int PgDatabase::GetLength(int tup_num, int field_num)
- </synopsis>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>GetLength</function>
- Returns the length of a field (attribute) in bytes. Tuple and field
- indices start at 0.
- <synopsis>
- int PgDatabase::GetLength(int tup_num, const char* field_name)
- </synopsis>
- 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.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>DisplayTuples</function>
- Prints out all the tuples and, optionally, the attribute names to the
- specified output stream.
- <synopsis>
- void PgDatabase::DisplayTuples(FILE *out = 0, int fillAlign = 1,
- const char* fieldSep = "|",int printHeader = 1, int quiet = 0)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>PrintTuples</function>
- Prints out all the tuples and, optionally, the attribute names to the
- specified output stream.
- <synopsis>
- void PgDatabase::PrintTuples(FILE *out = 0, int printAttName = 1,
- int terseOutput = 0, int width = 0)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>GetLine</function>
- <synopsis>
- int PgDatabase::GetLine(char* string, int length)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>PutLine</function>
- <synopsis>
- void PgDatabase::PutLine(const char* string)
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>OidStatus</function>
- <synopsis>
- const char *PgDatabase::OidStatus()
- </synopsis>
- </para>
- </listitem>
- <listitem>
- <para>
- <function>EndCopy</function>
- <synopsis>
- int PgDatabase::EndCopy()
- </synopsis>
- </para>
- </listitem>
- </itemizedlist>
- </para>
+ <title>Database Connection Functions</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <function>PgConnection</function>
+ makes a new connection to a backend database server.
+ <synopsis>
+ PgConnection::PgConnection(const char *conninfo)
+ </synopsis>
+ Although typically called from one of the access classes, a connection to
+ a backend server is possible by creating a PgConnection object.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>ConnectionBad</function>
+ returns whether or not the connection to the backend server succeeded or
+ failed.
+ <synopsis>
+ int PgConnection::ConnectionBad()
+ </synopsis>
+ Returns TRUE if the connection failed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>Status</function>
+ returns the status of the connection to the backend server.
+ <synopsis>
+ ConnStatusType PgConnection::Status()
+ </synopsis>
+ Returns either CONNECTION_OK or CONNECTION_BAD depending on the state
+ of the connection.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>PgDatabase</function>
+ makes a new connection to a backend database server.
+ <synopsis>
+ PgDatabase(const char *conninfo)
+ </synopsis>
+ 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
+ <function>Status</function> or <function>ConnectionBad</function> methods.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>DBName</function>
+ Returns the name of the current database.
+ <synopsis>
+ const char *PgConnection::DBName()
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>Notifies</function>
+ Returns the next notification from a list of unhandled notification messages
+ received from the backend.
+ <synopsis>
+ PGnotify* PgConnection::Notifies()
+ </synopsis>
+ See PQnotifies() for details.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
</sect1>
+
<sect1>
- <title>Asynchronous Notification</title>
+ <title>Query Execution Functions</title>
+ <para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <function>Exec</function>
+ Sends a query to the backend server. It's probably more desirable to
+ use one of the next two functions.
+ <synopsis>
+ ExecStatusType PgConnection::Exec(const char* query)
+ </synopsis>
+ Returns the result of the query. The following status results can be expected:
+
+ <simplelist>
+ <member>
+ PGRES_EMPTY_QUERY
+ </member>
+ <member>
+ PGRES_COMMAND_OK, if the query was a command
+ </member>
+ <member>
+ PGRES_TUPLES_OK, if the query successfully returned tuples
+ </member>
+ <member>
+ PGRES_COPY_OUT
+ </member>
+ <member>
+ PGRES_COPY_IN
+ </member>
+ <member>
+ PGRES_BAD_RESPONSE, if an unexpected response was received
+ </member>
+ <member>
+ PGRES_NONFATAL_ERROR
+ </member>
+ <member>
+ PGRES_FATAL_ERROR
+ </member>
+ </simplelist>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>ExecCommandOk</function>
+ Sends a command query to the backend server.
+ <synopsis>
+ int PgConnection::ExecCommandOk(const char *query)
+ </synopsis>
+ Returns TRUE if the command query succeeds.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>ExecTuplesOk</function>
+ Sends a command query to the backend server.
+ <synopsis>
+ int PgConnection::ExecTuplesOk(const char *query)
+ </synopsis>
+ Returns TRUE if the command query succeeds and there are tuples to be retrieved.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>ErrorMessage</function>
+ Returns the last error message text.
+ <synopsis>
+ const char *PgConnection::ErrorMessage()
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>Tuples</function>
+ Returns the number of tuples (instances) in the query result.
+ <synopsis>
+ int PgDatabase::Tuples()
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>Fields</function>
+ Returns the number of fields (attributes) in each tuple of the query result.
+ <synopsis>
+ int PgDatabase::Fields()
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>FieldName</function>
+ Returns the field (attribute) name associated with the given field index.
+ Field indices start at 0.
+ <synopsis>
+ const char *PgDatabase::FieldName(int field_num)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>FieldNum</function>
+ PQfnumber Returns the field (attribute) index associated with
+ the given field name.
+ <synopsis>
+ int PgDatabase::FieldNum(const char* field_name)
+ </synopsis>
+ -1 is returned if the given name does not match any field.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>FieldType</function>
+ 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.
+ <synopsis>
+ Oid PgDatabase::FieldType(int field_num)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>FieldType</function>
+ 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.
+ <synopsis>
+ Oid PgDatabase::FieldType(const char* field_name)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>FieldSize</function>
+ Returns the size in bytes of the field associated with the given
+ field index. Field indices start at 0.
+ <synopsis>
+ short PgDatabase::FieldSize(int field_num)
+ </synopsis>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>FieldSize</function>
+ Returns the size in bytes of the field associated with the given
+ field index. Field indices start at 0.
+ <synopsis>
+ short PgDatabase::FieldSize(const char *field_name)
+ </synopsis>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>GetValue</function>
+ Returns a single field (attribute) value of one tuple of a PGresult.
+ Tuple and field indices start at 0.
+ <synopsis>
+ const char *PgDatabase::GetValue(int tup_num, int field_num)
+ </synopsis>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>GetValue</function>
+ Returns a single field (attribute) value of one tuple of a PGresult.
+ Tuple and field indices start at 0.
+ <synopsis>
+ const char *PgDatabase::GetValue(int tup_num, const char *field_name)
+ </synopsis>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>GetLength</function>
+ Returns the length of a field (attribute) in bytes. Tuple and field
+ indices start at 0.
+ <synopsis>
+ int PgDatabase::GetLength(int tup_num, int field_num)
+ </synopsis>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>GetLength</function>
+ Returns the length of a field (attribute) in bytes. Tuple and field
+ indices start at 0.
+ <synopsis>
+ int PgDatabase::GetLength(int tup_num, const char* field_name)
+ </synopsis>
+ 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.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>DisplayTuples</function>
+ Prints out all the tuples and, optionally, the attribute names to the
+ specified output stream.
+ <synopsis>
+ void PgDatabase::DisplayTuples(FILE *out = 0, int fillAlign = 1,
+ const char* fieldSep = "|",int printHeader = 1, int quiet = 0)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>PrintTuples</function>
+ Prints out all the tuples and, optionally, the attribute names to the
+ specified output stream.
+ <synopsis>
+ void PgDatabase::PrintTuples(FILE *out = 0, int printAttName = 1,
+ int terseOutput = 0, int width = 0)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>GetLine</function>
+ <synopsis>
+ int PgDatabase::GetLine(char* string, int length)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>PutLine</function>
+ <synopsis>
+ void PgDatabase::PutLine(const char* string)
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>OidStatus</function>
+ <synopsis>
+ const char *PgDatabase::OidStatus()
+ </synopsis>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>EndCopy</function>
+ <synopsis>
+ int PgDatabase::EndCopy()
+ </synopsis>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </sect1>
+
+ <sect1>
+ <title>Asynchronous Notification</title>
-
<productname>Postgres</productname> supports asynchronous notification
- via the <command>LISTEN</command> and <command>NOTIFY</command>
- commands. A backend registers its interest in a particular semaphore
- with the <command>LISTEN</command> command.
- All backends that are listening on a
- particular named semaphore will be notified asynchronously when
- a <command>NOTIFY</command> 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.
-
- <note>
- 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.
- </para>
- </note>
- </para>
- <filename>libpq++</filename> 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 <filename>libpq++</filename> application
- must poll the backend to see if there is any pending notification
- information. After the execution of a query, a frontend may call
- <function>PgDatabase::Notifies</function>
- to see if any notification data is currently available from the backend.
- <function>PgDatabase::Notifies</function>
- 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.
- <function>PgDatabase::Notifies</function>
- behaves like the popping of a stack. Once a notification is returned
- from <function>PgDatabase::Notifies</function>,
- it is considered handled and will be removed from the list of
- notifications.
-
- <itemizedlist>
- <listitem>
- <function>PgDatabase::Notifies</function>
- retrieves pending notifications from the server.
-
- <synopsis>
- PGnotify* PgDatabase::Notifies()
- </synopsis>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- The second sample program gives an example of the use of asynchronous
- notification.
- </para>
+ <para>
+ <productname>Postgres</productname> supports asynchronous notification
+ via the <command>LISTEN</command> and <command>NOTIFY</command>
+ commands. A backend registers its interest in a particular semaphore
+ with the <command>LISTEN</command> command.
+ All backends that are listening on a
+ particular named semaphore will be notified asynchronously when
+ a <command>NOTIFY</command> 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.
+
+ <note>
+ <para>
+ 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.
+ </para>
+ </note>
+ </para>
+ <para>
+ <filename>libpq++</filename> 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 <filename>libpq++</filename> application
+ must poll the backend to see if there is any pending notification
+ information. After the execution of a query, a frontend may call
+ <function>PgDatabase::Notifies</function>
+ to see if any notification data is currently available from the backend.
+ <function>PgDatabase::Notifies</function>
+ 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.
+ <function>PgDatabase::Notifies</function>
+ behaves like the popping of a stack. Once a notification is returned
+ from <function>PgDatabase::Notifies</function>,
+ it is considered handled and will be removed from the list of
+ notifications.
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <function>PgDatabase::Notifies</function>
+ retrieves pending notifications from the server.
+
+ <synopsis>
+ PGnotify* PgDatabase::Notifies()
+ </synopsis>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ The second sample program gives an example of the use of asynchronous
+ notification.
+ </para>
</sect1>
+
<sect1>
- <title>Functions Associated with the COPY Command</title>
+ <title>Functions Associated with the COPY Command</title>
+
+ <para>
+ The <command>copy</command> command in <productname>Postgres</productname>
+ has options to read from or write to the network
+ connection used by <filename>libpq++</filename>.
+ Therefore, functions are necessary to
+ access this network connection directly so applications may take full
+ advantage of this capability.
- <para>
- The <command>copy</command> command in <productname>Postgres</productname>
- has options to read from or write to the network
- connection used by <filename>libpq++</filename>.
- Therefore, functions are necessary to
- access this network connection directly so applications may take full
- advantage of this capability.
-
- <itemizedlist>
- <listitem>
- <para>
- <function>PgDatabase::GetLine</function>
- reads a newline-terminated line of characters (transmitted by the
- backend server) into a buffer
- <replaceable class="parameter">string</replaceable>
- of size <replaceable class="parameter">length</replaceable>.
- <synopsis>
- int PgDatabase::GetLine(char* string, int length)
- </synopsis>
- </para>
- <para>
- Like the Unix system routine
- <function>fgets (3)</function>,
- this routine copies up to
- <literal><replaceable class="parameter">length</replaceable>-1</literal>
- characters into
- <replaceable class="parameter">string</replaceable>.
- It is like
- <function>gets (3)</function>,
- however, in that it converts the terminating newline into a null
- character.
- </para>
- <para>
- <function>PgDatabase::GetLine</function>
- 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.
- </para>
- <para>
- 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
- <command>copy</command>.
- Therefore, if the application ever expects to receive lines
- that are more than
- <literal><replaceable class="parameter">length</replaceable>-1</literal>
- characters long, the application must be sure to check the return
- value of <function>PgDatabase::GetLine</function> very carefully.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>PgDatabase::PutLine</function>
- Sends a null-terminated <replaceable class="parameter">string</replaceable>
- to the backend server.
- <synopsis>
- void PgDatabase::PutLine(char* string)
- </synopsis>
- </para>
- <para>
- The application must explicitly send a single period character (".")
- to indicate to the backend that it has finished sending its data.
- </para>
- </listitem>
- <listitem>
- <para>
- <function>PgDatabase::EndCopy</function>
- syncs with the backend.
- <synopsis>
- int PgDatabase::EndCopy()
- </synopsis>
- This function waits until the backend has
- finished processing the <command>copy</command>.
- It should either be issued when the
- last string has been sent to the backend using
- <function>PgDatabase::PutLine</function>
- or when the last string has been received from the backend using
- <function>PgDatabase::GetLine</function>.
- It must be issued or the backend may get <quote>out of sync</quote> with
- the frontend. Upon return from this function, the backend is ready to
- receive the next query.
- </para>
- <para>
- The return value is 0 on successful completion, nonzero otherwise.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
- As an example:
-
- <programlisting>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <function>PgDatabase::GetLine</function>
+ reads a newline-terminated line of characters (transmitted by the
+ backend server) into a buffer
+ <replaceable class="parameter">string</replaceable>
+ of size <replaceable class="parameter">length</replaceable>.
+ <synopsis>
+ int PgDatabase::GetLine(char* string, int length)
+ </synopsis>
+ </para>
+ <para>
+ Like the Unix system routine
+ <function>fgets (3)</function>,
+ this routine copies up to
+ <literal><replaceable class="parameter">length</replaceable>-1</literal>
+ characters into
+ <replaceable class="parameter">string</replaceable>.
+ It is like
+ <function>gets (3)</function>,
+ however, in that it converts the terminating newline into a null
+ character.
+ </para>
+ <para>
+ <function>PgDatabase::GetLine</function>
+ 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.
+ </para>
+ <para>
+ 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
+ <command>copy</command>.
+ Therefore, if the application ever expects to receive lines
+ that are more than
+ <literal><replaceable class="parameter">length</replaceable>-1</literal>
+ characters long, the application must be sure to check the return
+ value of <function>PgDatabase::GetLine</function> very carefully.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>PgDatabase::PutLine</function>
+ Sends a null-terminated <replaceable class="parameter">string</replaceable>
+ to the backend server.
+ <synopsis>
+ void PgDatabase::PutLine(char* string)
+ </synopsis>
+ </para>
+ <para>
+ The application must explicitly send a single period character (".")
+ to indicate to the backend that it has finished sending its data.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <function>PgDatabase::EndCopy</function>
+ syncs with the backend.
+ <synopsis>
+ int PgDatabase::EndCopy()
+ </synopsis>
+ This function waits until the backend has
+ finished processing the <command>copy</command>.
+ It should either be issued when the
+ last string has been sent to the backend using
+ <function>PgDatabase::PutLine</function>
+ or when the last string has been received from the backend using
+ <function>PgDatabase::GetLine</function>.
+ It must be issued or the backend may get <quote>out of sync</quote> with
+ the frontend. Upon return from this function, the backend is ready to
+ receive the next query.
+ </para>
+ <para>
+ The return value is 0 on successful completion, nonzero otherwise.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ As an example:
+
+ <programlisting>
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();
-
- </programlisting>
- </para>
+ </programlisting>
+ </para>
</sect1>
+
<sect1>
- <title>Caveats</title>
+ <title>Caveats</title>
- The query buffer is 8192 bytes long, and queries over that length will
- be silently truncated.
- </para>
+ <para>
+ The query buffer is 8192 bytes long, and queries over that length will
+ be silently truncated.
+ </para>
</sect1>
</chapter>
macro file. This is an example
<filename>~/axhome/macros/login.am</filename> file:
-=======
-<productname>ApplixWare</productname> must be configured correctly
- in order for it to
-be able to access the <productname>Postgres</productname>
- <acronym>ODBC</acronym> software drivers.
-</para>
-<procedure>
-<title>Enabling ApplixWare Database Access</title>
-
-<para>
-Note that
-these instructions are for the 4.4.1 release of
- <productname>ApplixWare</productname> on <productname>Linux</productname>.
-Refer to the <citetitle>Linux Sys Admin</citetitle> on-line book
- for more detailed information.
-</para>
-<step performance="required">
-<para>
-You must modify <filename>axnet.cnf</filename> so that
- <filename>elfodbc</filename> can
-find <filename>libodbc.so</filename>
- (the <acronym>ODBC</acronym> driver manager) shared library.
-This library is included with the ApplixWare distribution,
-but <filename>axnet.cnf</filename> needs to be modified to point to the
-correct location.
-</para>
-<para>
-As root, edit the file
-<filename><replaceable>applixroot</replaceable>/applix/axdata/axnet.cnf</filename>.
-</para>
-<substeps>
-
-<step performance="required">
-<para>
-At the bottom of <filename>axnet.cnf</filename>,
-find the line that starts with
-
-<programlisting>
-#libFor elfodbc /ax/<replaceable>...</replaceable>
-</programlisting>
-</para>
-</step>
-
-<step performance="required">
-<para>
-Change line to read
-
-<programlisting>
-libFor elfodbc <replaceable>applixroot</replaceable>/applix/axdata/axshlib/lib
-</programlisting>
-
-which will tell elfodbc to look in this directory
-for the <acronym>ODBC</acronym> support library.
-If you have installed applix somewhere else,
-change the path accordingly.
-</para>
-</step>
-
-</substeps>
-</step>
-
-<step performance="required">
-<para>
-Create <filename>.odbc.ini</filename> as
-described above. You may also want to add the flag
-
-<programlisting>
-TextAsLongVarchar=0
-</programlisting>
-
-to the database-specific portion of <filename>.odbc.ini</filename>
-so that text fields will not be shown as <literal>**BLOB**</literal>.
-</para>
-</step>
-
-</procedure>
-
-<procedure>
-<title>Testing ApplixWare ODBC Connections</title>
-
-<step performance="required">
-<para>
- Bring up <application>Applix Data</application>
-</para>
-</step>
-
-<step performance="required">
-<para>
-Select the <productname>Postgres</productname> database of interest.
-</para>
-
-<substeps>
-
-<step performance="required">
-<para>
-Select <command>Query->Choose Server</command>.
-</para>
-</step>
-
-<step performance="required">
-<para>
- Select <acronym>ODBC</acronym>, and click <command>Browse</command>.
-The database you configured in <filename>.odbc.ini</filename>
- should be shown. Make sure that the <option>Host: field</option>
- is empty (if it is not, axnet will try to contact axnet on another machine
- to look for the database).
-</para>
-</step>
-
-<step performance="required">
-<para>
-Select the database in the box that was launched by <command>Browse</command>,
- then click <command>OK</command>.
-</para>
-</step>
-
-<step performance="required">
-<para>
-Enter username and password in the login identification dialog,
- and click <command>OK</command>.
-</para>
-</step>
-
-</substeps>
-
-<para>
- You should see <quote>Starting elfodbc server</quote>
- in the lower left corner of the
- data window. If you get an error dialog box, see the debugging section
- below.
-</para>
-</step>
-<step performance="required">
-<para>
- The 'Ready' message will appear in the lower left corner of the data
- window. This indicates that you can now enter queries.
-</para>
-</step>
-
-<step performance="required">
-<para>
- Select a table from Query->Choose tables, and then select Query->Query
- to access the database. The first 50 or so rows from the table should
- appear.
-</para>
-</step>
-
-</procedure>
-</sect2>
-
-<sect2>
-<title>Common Problems</title>
-
-<para>
-The following messages can appear while trying to make an
-<acronym>ODBC</acronym> connection through
-<productname>Applix Data</productname>:
-
-<variablelist>
-<varlistentry>
-<term>
-Cannot launch gateway on server
-</term>
-<listitem>
-<para>
-<literal>elfodbc</literal> can't find <filename>libodbc.so</filename>.
-Check your <filename>axnet.cnf</filename>.
-</para>
-</listitem>
-</varlistentry>
-<varlistentry>
-<term>
-Error from ODBC Gateway:
-IM003::[iODBC][Driver Manager]Specified driver could not be loaded
-</term>
-
-<listitem>
-<para>
-<filename>libodbc.so</filename> cannot find the driver listed in
-<filename>.odbc.ini</filename>. Verify the settings.
-</para>
-</listitem>
-</varlistentry>
-
-<varlistentry>
-<term>
-Server: Broken Pipe
-</term>
-
-<listitem>
-<para>
- The driver process has terminated due to some other
- problem. You might not have an up-to-date version
- of the <productname>Postgres</productname>
-<acronym>ODBC</acronym> package.
-</para>
-</listitem>
-</varlistentry>
-
-</variablelist>
-</para>
-</sect2>
-
-<sect2>
-<title>Debugging ApplixWare ODBC Connections</title>
-
-<para>
-One good tool for debugging connection problems uses the Unix system
-utility <application>strace</application>.
-</para>
-<procedure>
-<title>Debugging with strace</title>
-
-<step performance="required">
-<para>
-Start applixware.
-</para>
-</step>
-<step performance="required">
-<para>
-Start an <application>strace</application> on
-the axnet process. For example, if
-
-<programlisting>
-ps -aucx | grep ax
-</programlisting>
-
-shows
-
-<programlisting>
-cary 10432 0.0 2.6 1740 392 ? S Oct 9 0:00 axnet
-cary 27883 0.9 31.0 12692 4596 ? S 10:24 0:04 axmain
-</programlisting>
-</para>
-
-<para>
-Then run
-
-<programlisting>
- strace -f -s 1024 -p 10432
-</programlisting>
-</para>
-</step>
-<step performance="required">
-<para>
-Check the strace output.
-</para>
-
-<note>
-<title>Note from Cary</title>
-
-<para>
-Many of the error messages from <productname>ApplixWare</productname>
-go to <filename>stderr</filename>,
-but I'm not sure where <filename>stderr</filename>
-is sent, so <application>strace</application> is the way to find out.
-</para>
-</note>
-</step>
-</procedure>
-
-<para>
- For example, after getting
-a <quote>Cannot launch gateway on server</quote>,
-I ran strace on axnet and got
-
-<programlisting>
-[pid 27947] open("/usr/lib/libodbc.so", O_RDONLY) = -1 ENOENT
- (No such file or directory)
-[pid 27947] open("/lib/libodbc.so", O_RDONLY) = -1 ENOENT
- (No such file or directory)
-[pid 27947] write(2, "/usr2/applix/axdata/elfodbc:
- can't load library 'libodbc.so'\n", 61) = -1 EIO (I/O error)
-</programlisting>
-So what is happening is that applix elfodbc is searching for libodbc.so, but it
-can't find it. That is why axnet.cnf needed to be changed.
-</para>
-</sect2>
-<sect2>
-<title>Running the ApplixWare Demo</title>
-
-<para>
-In order to go through the
-<citetitle>ApplixWare Data Tutorial</citetitle>, you need to create
-the sample tables that the Tutorial refers to. The ELF Macro used to
-create the tables tries to use a NULL condition
-on many of the database columns,
-and <productname>Postgres</productname> does not currently allow this option.
-</para>
-
-<para>
-To get around this problem, you can do the following:
-</para>
-
-<procedure>
-<title>Modifying the ApplixWare Demo</title>
-
-<step performance="required">
-<para>
-Copy <filename>/opt/applix/axdata/eng/Demos/sqldemo.am</filename>
- to a local directory.
-</para>
-</step>
-
-<step performance="required">
-<para>
-Edit this local copy of <filename>sqldemo.am</filename>:
-</para>
-
-<substeps>
-
-<step performance="required">
-<para>
-Search for 'null_clause = "NULL"
-</para>
-</step>
-
-<step performance="required">
-<para>
-Change this to null_clause = ""
-</para>
-</step>
-</substeps>
-</step>
-<step performance="required">
-<para>
-Start <application>Applix Macro Editor</application>.
-</para>
-</step>
-<step performance="required">
-<para>
-Open the sqldemo.am file from the <application>Macro Editor</application>.
-</para>
-</step>
-
-<step performance="required">
-<para>
-Select <command>File->Compile and Save</command>.
-</para>
-</step>
-
-<step performance="required">
-<para>
-Exit <application>Macro Editor</application>.
-</para>
-</step>
-
-<step performance="required">
-<para>
-Start <application>Applix Data</application>.
-</para>
-</step>
-
-<step performance="required">
-<para>
-Select <command>*->Run Macro</command>
-</para>
-</step>
-
-<step performance="required">
-<para>
-Enter the value <quote>sqldemo</quote>, then click <command>OK</command>.
-</para>
-
-<para>
-You should see the progress in the status line of the data window
- (in the lower left corner).
-</para>
-</step>
-
-<step performance="required">
-<para>
-You should now be able to access the demo tables.
-</para>
-</step>
-
-</procedure>
-</sect2>
-
-<sect2>
-<title>Useful Macros</title>
-
-<para>
-You can add information about your
-database login and password to the standard Applix startup
-macro file. This is an example
-<filename>~/axhome/macros/login.am</filename> file:
-
<programlisting>
macro login
set_set_system_var@("sql_username@","tgl")
-<Chapter Id="release">
-<Title>Release Notes</Title>
+ <chapter>
+ <title>Release Notes</title>
-<Sect1>
-<Title>Release 6.5</Title>
+ <sect1>
+ <title>Release 6.5</title>
<!--
<docinfo>
<authorgroup>
</docinfo>
-->
-<para>
-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:
-
-<itemizedlist spacing="compact">
-<listitem>
-<para>
-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.
-</para>
-</listitem>
-<listitem>
-<para>
-Numeric data type: We now have a true numeric data type, with
-user-specified precision.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Temporary tables: Temporary tables are guaranteed to have unique names
-within a database session, and are destroyed on session exit.
-</para>
-</listitem>
-
-<listitem>
-<para>
-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.
-</para>
-</listitem>
-
-<listitem>
-<para>
-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.
-</para>
-</listitem>
-
-<listitem>
-<para>
-Other: We continue to expand our port list, this time including
-Win32/NT. Most interfaces have new versions, and existing functionality
-has been improved.
-</para>
-</listitem>
-
-</itemizedlist>
-</para>
-
-<sect2>
-<title>Migration to v6.5</title>
-
-<para>
-A dump/restore using <application>pg_dump</application>
-or <application>pg_dumpall</application>
-is required for those wishing to migrate data from any
-previous release of <productname>Postgres</productname>.
-</para>
-</sect2>
-<sect2>
-<title>Detailed Change List</title>
-
-<para>
-<programlisting>
+ <para>
+ 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.
+ </para>
+
+ <para>
+ Here is a brief summary of some of the more noticable changes:
+
+ <variablelist>
+ <varlistentry>
+ <term>
+ Multi-version concurrency control(MVCC)
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ Numeric data type
+ </term>
+ <listitem>
+ <para>
+ We now have a true numeric data type, with
+ user-specified precision.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ Temporary tables
+ </term>
+ <listitem>
+ <para>
+ Temporary tables are guaranteed to have unique names
+ within a database session, and are destroyed on session exit.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ New SQL features
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ Speedups
+ </term>
+ <listitem>
+ <para>
+ 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.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ Ports
+ </term>
+ <listitem>
+ <para>
+ We continue to expand our port list, this time including
+ WinNT/ix86 and NetBSD/arm32.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ Interfaces
+ </term>
+ <listitem>
+ <para>
+ Most interfaces have new versions, and existing functionality
+ has been improved.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </para>
+
+ <sect2>
+ <title>Migration to v6.5</title>
+
+ <para>
+ A dump/restore using <application>pg_dump</application>
+ or <application>pg_dumpall</application>
+ is required for those wishing to migrate data from any
+ previous release of <productname>Postgres</productname>.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Detailed Change List</title>
+
+ <para>
+ <programlisting>
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)
-</programlisting>
-</Para>
-</sect2>
-</Sect1>
+ </programlisting>
+ </para>
+ </sect2>
+ </sect1>
-<Sect1>
-<Title>Release 6.4.2</Title>
+<sect1>
+<title>Release 6.4.2</title>
<!--
<docinfo>
<authorgroup>
<programlisting>
Fix for datetime constant problem on some platforms(Thomas)
</programlisting>
-</Para>
+</para>
</sect2>
-</Sect1>
+</sect1>
-<Sect1>
-<Title>Release 6.4.1</Title>
+<sect1>
+<title>Release 6.4.1</title>
<!--
<docinfo>
<authorgroup>
Compilation of libpq for Win32 fixes(Magnus)
Upgrade to PyGreSQL 2.2(D'Arcy)
</programlisting>
-</Para>
+</para>
</sect2>
-</Sect1>
+</sect1>
-<Sect1>
-<Title>Release 6.4</Title>
+<sect1>
+<title>Release 6.4</title>
<!--
<docinfo>
<authorgroup>
has received some attention since the previous release.
Here is a brief, incomplete summary:
-<itemizedlist spacing="compact">
+<itemizedlist>
<listitem>
<para>
Views and rules are now functional thanks to extensive new code in the
configure uses supplied install-sh if no install script found(Tom)
new Makefile.shlib for shared library configuration(Tom)
</programlisting>
-</Para>
+</para>
</sect2>
-</Sect1>
+</sect1>
-<Sect1>
-<Title>Release 6.3.2</Title>
+<sect1>
+<title>Release 6.3.2</title>
<!--
<docinfo>
<authorgroup>
<para>
Summary:
-<itemizedlist spacing="compact">
+<itemizedlist>
<listitem>
<para>
Repairs automatic configuration support for some platforms, including Linux,
</itemizedlist>
</para>
-<Para>
+<para>
A dump/restore is NOT required for those running 6.3 or 6.3.1. A
'make distclean', 'make', and 'make install' is all that is required.
This last step should be performed while the postmaster is not running.
</para>
</sect2>
</sect1>
-<Sect1>
-<Title>Release 6.3.1</Title>
+<sect1>
+<title>Release 6.3.1</title>
<!--
<docinfo>
<authorgroup>
<para>
Summary:
-<itemizedlist spacing="compact">
+<itemizedlist>
<listitem>
<para>
Additional support for multi-byte character sets.
</itemizedlist>
</para>
-<Para>
+<para>
A dump/restore is NOT required for those running 6.3. A
'make distclean', 'make', and 'make install' is all that is required.
This last step should be performed while the postmaster is not running.
</para>
</sect2>
</sect1>
-<Sect1>
-<Title>Release 6.3</Title>
+<sect1>
+<title>Release 6.3</title>
<!--
<docinfo>
<authorgroup>
There are <emphasis>many</emphasis> new features and improvements in this release.
Here is a brief, incomplete summary:
-<itemizedlist spacing="compact">
+<itemizedlist>
<listitem>
<para>
Many new SQL features, including
Expand a few function names formerly truncated to 16 characters(Thomas)
Remove un-needed malloc() calls and replace with palloc()(Bruce)
</programlisting>
-</Para>
+</para>
</sect2>
-</Sect1>
+</sect1>
-<Sect1>
-<Title>Release 6.2.1</Title>
+<sect1>
+<title>Release 6.2.1</title>
<!--
<docinfo>
<authorgroup>
<para>
Summary:
-<itemizedlist spacing="compact">
+<itemizedlist>
<listitem>
<para>
Allow strings to span lines, per <acronym>SQL92</acronym>.
</programlisting>
</para>
</sect2>
-</Sect1>
+</sect1>
-<Sect1>
-<Title>Release 6.2</Title>
+<sect1>
+<title>Release 6.2</title>
<!--
<docinfo>
<authorgroup>
</sect2>
</sect1>
-<Sect1>
-<Title>Release 6.1.1</Title>
+<sect1>
+<title>Release 6.1.1</title>
<!--
<docinfo>
<authorgroup>
</sect2>
</sect1>
-<Sect1>
-<Title>Release 6.1</Title>
+<sect1>
+<title>Release 6.1</title>
<!--
<docinfo>
<authorgroup>
</docinfo>
-->
-<Para>
+<para>
The regression tests have been adapted and extensively modified for the
v6.1 release of <productname>Postgres</productname>.
-</Para>
+</para>
-<Para>
+<para>
Three new data types (datetime, timespan, and circle) have been added to
the native set of <productname>Postgres</productname> 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>
-<Para>
- <productname>Postgres</productname> v6.1 introduces a new, alternate optimizer which uses <FirstTerm>genetic</FirstTerm>
+<para>
+ <productname>Postgres</productname> v6.1 introduces a new, alternate
+optimizer which uses <firstterm>genetic</firstterm>
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'</Command> and <Command>reset geqo</Command>.
-</Para>
+ <command>set geqo to 'off'</command> and <command>reset geqo</command>.
+</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/*.out</FileName> files reflect this
+ tests were generated. The current <filename>./expected/*.out</filename> 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>
<sect2>
<title>Migration to v6.1</title>
</para>
</sect1>
-<Sect1>
-<Title>Timing Results</Title>
+<sect1>
+<title>Timing Results</title>
-<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>
+<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.
</para>
-<Sect2>
-<Title>v6.4beta</Title>
+<sect2>
+<title>v6.4beta</title>
<para>
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>
-<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>
</para>
</sect2>
-<Sect2>
-<Title>v6.3</Title>
+<sect2>
+<title>v6.3</title>
<para>
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>
-<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>
</para>
</sect2>
-<Sect2>
-<Title>v6.1</Title>
+<sect2>
+<title>v6.1</title>
-<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>
</para>
</sect2>
</sect1>
-</Chapter>
+</chapter>
+
+<!-- Keep this comment at the end of the file
+Local variables:
+mode: sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+sgml-parent-document:nil
+sgml-default-dtd-file:"./reference.ced"
+sgml-exposed-tags:nil
+sgml-local-catalogs:"/usr/lib/sgml/catalog"
+sgml-local-ecat-files:nil
+End:
+-->
projects / postgresql / commitdiff