From f3d2b2e0c7c9eb9d79f26591f844d6edb123335c Mon Sep 17 00:00:00 2001 From: "Thomas G. Lockhart" Date: Thu, 3 Jun 1999 04:21:51 +0000 Subject: [PATCH] Markup changes for v6.5 release. Clean out duplicate stuff in odbc.sgml resulting from a faulty patch. --- doc/src/sgml/admin.sgml | 8 +- doc/src/sgml/installation.sgml | 99 +-- doc/src/sgml/legal.sgml | 94 +-- doc/src/sgml/libpq++.sgml | 1431 ++++++++++++++++++++-------------------- doc/src/sgml/odbc.sgml | 388 ----------- doc/src/sgml/postgres.sgml | 44 +- doc/src/sgml/programmer.sgml | 8 +- doc/src/sgml/release.sgml | 382 ++++++----- doc/src/sgml/tutorial.sgml | 12 +- doc/src/sgml/user.sgml | 10 +- 10 files changed, 1104 insertions(+), 1372 deletions(-) diff --git a/doc/src/sgml/admin.sgml b/doc/src/sgml/admin.sgml index fecc728009..370c23ea35 100644 --- a/doc/src/sgml/admin.sgml +++ b/doc/src/sgml/admin.sgml @@ -1,11 +1,15 @@ -PostgreSQL Installation Guide - - Covering v6.5 for general release - - - The PostgreSQL Development Team - +PostgreSQL Installation Guide + + Covering v6.5 for general release + + + The PostgreSQL Development Team + - - Thomas - Lockhart - - Caltech/JPL - - + + Thomas + Lockhart + + Caltech/JPL + + @@ -80,17 +83,17 @@ First cut at standalone installation guide to replace INSTALL text source. TGL --> - (last updated 1999-06-01) - + (last updated 1999-06-01) + - - -PostgreSQL is © 1998-9 + + +PostgreSQL is © 1998-9 by the Postgres Global Development Group. - - + + - + - -Summary + +Summary - -Postgres, + +Postgres, developed originally in the UC Berkeley Computer Science Department, pioneered many of the object-relational concepts now becoming available in some commercial databases. It provides SQL92/SQL3 language support, transaction integrity, and type extensibility. - PostgreSQL is a public-domain, open source descendant + PostgreSQL is a public-domain, open source descendant of this original Berkeley code. - - + + - + Introduction @@ -129,24 +132,34 @@ and runtime environment for your system. This may be adequate for many installat and is almost certainly adequate for a first installation. But you may want to do an initial installation up to the point of unpacking the source tree and installing documentation, and then print or browse the -Administrator's Guide. +Administrator's Guide. &ports; &install; &config; - - -Release Notes - -¤t; - - +&release; - - + + + diff --git a/doc/src/sgml/legal.sgml b/doc/src/sgml/legal.sgml index 62e486b0bf..8078fa3433 100644 --- a/doc/src/sgml/legal.sgml +++ b/doc/src/sgml/legal.sgml @@ -1,43 +1,59 @@ - -Copyrights and Trademarks + + Copyrights and Trademarks - -PostgreSQL is copyright (C) 1996-8 -by the PostgreSQL Global Development Group, -and is distributed under the terms of the Berkeley license. - + + PostgreSQL is Copyright © 1996-9 + by the PostgreSQL Global Development Group, + and is distributed under the terms of the Berkeley license. + - -Postgres95 is copyright (C) 1994-5 -by the Regents of the University of California. -Permission to use, copy, modify, and distribute this software and its documentation -for any purpose, without fee, and without a written agreement is hereby granted, -provided that the above copyright notice and this paragraph and the following two -paragraphs appear in all copies. - - -In no event shall the University of California be liable to -any party for direct, indirect, special, incidental, or consequential -damages, including lost profits, arising out of the use of this -software and its documentation, even if the University of California -has been advised of the possibility of such damage. - - -The University of California specifically disclaims any -warranties, including, but not limited to, the implied warranties -of merchantability and fitness for a particular purpose. -The software provided hereunder is on an "as-is" basis, and -the University of California has no obligations to provide -maintainance, support, updates, enhancements, or modifications. - + + Postgres95 is Copyright © 1994-5 + by the Regents of the University of California. + Permission to use, copy, modify, and distribute this software and its documentation + for any purpose, without fee, and without a written agreement is hereby granted, + provided that the above copyright notice and this paragraph and the following two + paragraphs appear in all copies. + + + In no event shall the University of California be liable to + any party for direct, indirect, special, incidental, or consequential + damages, including lost profits, arising out of the use of this + software and its documentation, even if the University of California + has been advised of the possibility of such damage. + + + The University of California specifically disclaims any + warranties, including, but not limited to, the implied warranties + of merchantability and fitness for a particular purpose. + The software provided hereunder is on an "as-is" basis, and + the University of California has no obligations to provide + maintainance, support, updates, enhancements, or modifications. + - -UNIX is a trademark of X/Open, Ltd. Sun4, SPARC, SunOS -and Solaris are trademarks of Sun Microsystems, Inc. DEC, -DECstation, Alpha AXP and ULTRIX are trademarks of Digital -Equipment Corp. PA-RISC and HP-UX are trademarks of -Hewlett-Packard Co. OSF/1 is a trademark of the Open -Software Foundation. - - + + UNIX is a trademark of X/Open, Ltd. Sun4, SPARC, SunOS + and Solaris are trademarks of Sun Microsystems, Inc. DEC, + DECstation, Alpha AXP and ULTRIX are trademarks of Digital + Equipment Corp. PA-RISC and HP-UX are trademarks of + Hewlett-Packard Co. OSF/1 is a trademark of the Open + Software Foundation. + + + diff --git a/doc/src/sgml/libpq++.sgml b/doc/src/sgml/libpq++.sgml index 4fab4d969f..8830709064 100644 --- a/doc/src/sgml/libpq++.sgml +++ b/doc/src/sgml/libpq++.sgml @@ -2,41 +2,44 @@ libpq C++ Binding - libpq++ is the C++ API to - Postgres. - 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 + Postgres. + 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. @@ -44,713 +47,721 @@ 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 - Postgres, - 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 - the Postgres backend. - - - - - 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 + Postgres, + 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 + the Postgres backend. + + + + + 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: <classname>PgConnection</classname> - - The connection class makes the actual connection to the database and is inherited - by all of the access classes. - - - - Database Class: <classname>PgDatabase</classname> - - 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: <classname>PgConnection</classname> + - - - - 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: <classname>PgDatabase</classname> + + + 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. + diff --git a/doc/src/sgml/odbc.sgml b/doc/src/sgml/odbc.sgml index d112c94e1e..82b6bc79e2 100644 --- a/doc/src/sgml/odbc.sgml +++ b/doc/src/sgml/odbc.sgml @@ -1047,394 +1047,6 @@ database login and password to the standard Applix startup macro file. This is an example ~/axhome/macros/login.am file: -======= -ApplixWare must be configured correctly - in order for it to -be able to access the Postgres - ODBC software drivers. - - -Enabling ApplixWare Database Access - - -Note that -these instructions are for the 4.4.1 release of - ApplixWare on Linux. -Refer to the Linux Sys Admin on-line book - for more detailed information. - - - -You must modify axnet.cnf so that - elfodbc can -find libodbc.so - (the ODBC driver manager) shared library. -This library is included with the ApplixWare distribution, -but axnet.cnf needs to be modified to point to the -correct location. - - -As root, edit the file -applixroot/applix/axdata/axnet.cnf. - - - - - -At the bottom of axnet.cnf, -find the line that starts with - - -#libFor elfodbc /ax/... - - - - - - -Change line to read - - -libFor elfodbc applixroot/applix/axdata/axshlib/lib - - -which will tell elfodbc to look in this directory -for the ODBC support library. -If you have installed applix somewhere else, -change the path accordingly. - - - - - - - - -Create .odbc.ini as -described above. You may also want to add the flag - - -TextAsLongVarchar=0 - - -to the database-specific portion of .odbc.ini -so that text fields will not be shown as **BLOB**. - - - - - - -Testing ApplixWare ODBC Connections - - - - Bring up Applix Data - - - - - -Select the Postgres database of interest. - - - - - - -Select Query->Choose Server. - - - - - - Select ODBC, and click Browse. -The database you configured in .odbc.ini - should be shown. Make sure that the - is empty (if it is not, axnet will try to contact axnet on another machine - to look for the database). - - - - - -Select the database in the box that was launched by Browse, - then click OK. - - - - - -Enter username and password in the login identification dialog, - and click OK. - - - - - - - You should see Starting elfodbc server - in the lower left corner of the - data window. If you get an error dialog box, see the debugging section - below. - - - - - The 'Ready' message will appear in the lower left corner of the data - window. This indicates that you can now enter queries. - - - - - - 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. - - - - - - - -Common Problems - - -The following messages can appear while trying to make an -ODBC connection through -Applix Data: - - - - -Cannot launch gateway on server - - - -elfodbc can't find libodbc.so. -Check your axnet.cnf. - - - - - -Error from ODBC Gateway: -IM003::[iODBC][Driver Manager]Specified driver could not be loaded - - - - -libodbc.so cannot find the driver listed in -.odbc.ini. Verify the settings. - - - - - - -Server: Broken Pipe - - - - - The driver process has terminated due to some other - problem. You might not have an up-to-date version - of the Postgres -ODBC package. - - - - - - - - - -Debugging ApplixWare ODBC Connections - - -One good tool for debugging connection problems uses the Unix system -utility strace. - - -Debugging with strace - - - -Start applixware. - - - - -Start an strace on -the axnet process. For example, if - - -ps -aucx | grep ax - - -shows - - -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 - - - - -Then run - - - strace -f -s 1024 -p 10432 - - - - - -Check the strace output. - - - -Note from Cary - - -Many of the error messages from ApplixWare -go to stderr, -but I'm not sure where stderr -is sent, so strace is the way to find out. - - - - - - - For example, after getting -a Cannot launch gateway on server, -I ran strace on axnet and got - - -[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) - -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. - - - -Running the ApplixWare Demo - - -In order to go through the -ApplixWare Data Tutorial, 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 Postgres does not currently allow this option. - - - -To get around this problem, you can do the following: - - - -Modifying the ApplixWare Demo - - - -Copy /opt/applix/axdata/eng/Demos/sqldemo.am - to a local directory. - - - - - -Edit this local copy of sqldemo.am: - - - - - - -Search for 'null_clause = "NULL" - - - - - -Change this to null_clause = "" - - - - - - -Start Applix Macro Editor. - - - - -Open the sqldemo.am file from the Macro Editor. - - - - - -Select File->Compile and Save. - - - - - -Exit Macro Editor. - - - - - -Start Applix Data. - - - - - -Select *->Run Macro - - - - - -Enter the value sqldemo, then click OK. - - - -You should see the progress in the status line of the data window - (in the lower left corner). - - - - - -You should now be able to access the demo tables. - - - - - - - -Useful Macros - - -You can add information about your -database login and password to the standard Applix startup -macro file. This is an example -~/axhome/macros/login.am file: - macro login set_set_system_var@("sql_username@","tgl") diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml index 4e85530a79..8e0ce49485 100644 --- a/doc/src/sgml/postgres.sgml +++ b/doc/src/sgml/postgres.sgml @@ -1,11 +1,15 @@ - - + + + @@ -121,7 +126,6 @@ Move SQL reference pages up into the User's Guide. - @@ -219,7 +223,7 @@ Move SQL reference pages up into the User's Guide. - PostgreSQL is © 1998-9 + PostgreSQL is Copyright © 1996-9 by the Postgres Global Development Group. @@ -254,20 +258,6 @@ Your name here... - - Tutorial - - - Introduction for new users. - - - &intro; - &arch; - &start; - &query; - &advanced; - - User's Guide @@ -276,7 +266,6 @@ Your name here... - &sql; &syntax; &datatype; &oper; @@ -383,6 +372,21 @@ Your name here... &page; + + Tutorial + + + Introduction for new users. + + + &intro; + &sql; + &arch; + &start; + &query; + &advanced; + + Appendices diff --git a/doc/src/sgml/programmer.sgml b/doc/src/sgml/programmer.sgml index eed86f1b17..61b6149a36 100644 --- a/doc/src/sgml/programmer.sgml +++ b/doc/src/sgml/programmer.sgml @@ -1,10 +1,14 @@ - -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 -or pg_dumpall -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 + or pg_dumpall + 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) @@ -237,14 +283,14 @@ Add ARM32 support(Andrew McMurry) 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) - - - - + + + + - -Release 6.4.2 + +Release 6.4.2 - + The regression tests have been adapted and extensively modified for the v6.1 release of Postgres. - + - + 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. - + - - 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 @@ -1493,28 +1540,28 @@ Sun Jun 8 14:41:13 EDT 1997 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 - set geqo to 'off' and reset geqo. - + set geqo to 'off' and reset geqo. + - + 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 ./expected/*.out files reflect this + tests were generated. The current ./expected/*.out files reflect this new interpretation, which may not be correct! - + - + 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. - + - + 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). - + Migration to v6.1 @@ -2440,40 +2487,40 @@ Initial release. - -Timing Results + +Timing Results - + These timing results are from running the regression test with the commands - + % cd src/test/regress % make all % time make runtest - + - + 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. - -v6.4beta + +v6.4beta 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!). - - + + Time System 02:26 Dual Pentium Pro 180, 96MB, UW-SCSI, Linux 2.0.30, gcc 2.7.2.1 -O2 -m486 - + - -v6.3 + +v6.3 The times for this release are not directly comparable to those for previous releases @@ -2481,26 +2528,43 @@ since some additional regression tests have been included and some obsolete test time travel have been removed. In general, however, v6.3 is substantially faster than previous releases (thanks, Bruce!). - - + + 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 - + - -v6.1 + +v6.1 - - + + 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 - + - + + + diff --git a/doc/src/sgml/tutorial.sgml b/doc/src/sgml/tutorial.sgml index f51b94192a..958a713d05 100644 --- a/doc/src/sgml/tutorial.sgml +++ b/doc/src/sgml/tutorial.sgml @@ -13,12 +13,13 @@ - - - - + + + + + ]> @@ -54,7 +55,7 @@ - PostgreSQL is copyright (©) 1998-9 + PostgreSQL is Copyright © 1996-9 by the Postgres Global Development Group. @@ -90,6 +91,7 @@ Your name here... &intro; + &sql; &arch; &start; &query; diff --git a/doc/src/sgml/user.sgml b/doc/src/sgml/user.sgml index 49bb634c6e..3323e160bd 100644 --- a/doc/src/sgml/user.sgml +++ b/doc/src/sgml/user.sgml @@ -1,11 +1,15 @@