From d98011d8dea452603edc1b173590a2a56cfb6460 Mon Sep 17 00:00:00 2001 From: "Thomas G. Lockhart" Date: Sat, 10 Oct 1998 17:12:18 +0000 Subject: [PATCH] Clean up markup. Add new bibliographic references from Paul Aoki. Include libpq++ docs from the old man page in the Programmer's Guide. Update Unix installation info for ODBC. --- doc/src/sgml/biblio.sgml | 120 +++++- doc/src/sgml/compiler.sgml | 2 +- doc/src/sgml/ecpg.sgml | 186 +++++---- doc/src/sgml/libpgtcl.sgml | 5 +- doc/src/sgml/libpq++.sgml | 584 ++++++++++++++++++++++++++ doc/src/sgml/libpq.sgml | 957 ++++++++++++++++++++++--------------------- doc/src/sgml/odbc.sgml | 145 +++++-- doc/src/sgml/ports.sgml | 40 +- doc/src/sgml/programmer.sgml | 12 +- 9 files changed, 1454 insertions(+), 597 deletions(-) create mode 100644 doc/src/sgml/libpq++.sgml diff --git a/doc/src/sgml/biblio.sgml b/doc/src/sgml/biblio.sgml index d7afdf60de..9dafe456c6 100644 --- a/doc/src/sgml/biblio.sgml +++ b/doc/src/sgml/biblio.sgml @@ -317,6 +317,40 @@ The POSTGRES Group + +Partial indexing in POSTGRES : research project + + +Olson, 1993 + + + +Nels +Olson + + +1993 +UCB Engin T7.49.1993 O676 + +University of California, Berkeley CA + + + + + + @@ -381,6 +415,55 @@ Rowe and Stonebraker, 1987 <!-- <BIBLIOMISC>‐</BIBLIOMISC> +<BOOKBIBLIO ID="SESHADRI95"> + +1. CONFERENCE PAPER + Seshadri, P.; Swami, A. + Generalized partial indexes. + IN: Proceedings of the Eleventh International Conference on Data + Engineering (Cat. No.95CH35724). (Proceedings of the Eleventh International + Conference on Data Engineering (Cat. No.95CH35724)Proceedings of the + Eleventh International Conference on Data Engineering, Taipei, Taiwan, 6-10 + March 1995). Edited by: Yu, P.S.; Chen, A.L.P. Los Alamitos, CA, USA: IEEE + Comput. Soc. Press, 1995. p. 420-7. +http://simon.cs.cornell.edu/home/praveen/papers/partindex.de95.ps.Z + +--> +<TITLE ID="SESHADRI95-full"> +<ulink url="http://simon.cs.cornell.edu/home/praveen/papers/partindex.de95.ps.Z"> +Generalized partial indexes +</ulink> + + + + + +P. +Seshadri + + +A. +Swami + + + +March 1995 +Eleventh International Conference on Data Engineering + +1995 +Cat. No.95CH35724 + +IEEE Computer Society Press + + + + + + @@ -388,7 +471,6 @@ The Design of <ProductName>Postgres</ProductName> Stonebraker and Rowe, 1986 -STON86 @@ -515,6 +597,42 @@ Stonebraker et al, 1989 + +<ulink url="http://s2k-ftp.CS.Berkeley.EDU:8000/postgres/papers/ERL-M89-17.pdf"> +The case for partial indexes (DBMS) +</ulink> + + +Stonebraker, M, 1989b + + +M. +Stonebraker + + + +Dec. 1989 +Record 18(no.4):4-11 +SIGMOD +1989 + + + + + + diff --git a/doc/src/sgml/compiler.sgml b/doc/src/sgml/compiler.sgml index f04b48b0ee..b7f8bef30e 100644 --- a/doc/src/sgml/compiler.sgml +++ b/doc/src/sgml/compiler.sgml @@ -9,7 +9,7 @@ <Date>Transcribed 1998-02-12</Date> </DocInfo> -<Title>GCC Default Optimizations +<application>gcc</application> Default Optimizations diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml index e460ae7e6b..7cb28cd8e1 100644 --- a/doc/src/sgml/ecpg.sgml +++ b/doc/src/sgml/ecpg.sgml @@ -21,10 +21,12 @@ Transcribed 1998-02-12 -<Application>ecpg</Application> - Embedded <Acronym>SQL</Acronym> in <Acronym>C</Acronym> +<Application>ecpg</Application> - Embedded <Acronym>SQL</Acronym> +in <Acronym>C</Acronym> -This describes an embedded SQL in C package for Postgres. +This describes an embedded SQL in C +package for Postgres. It is written by Linus Tolke and Michael Meskes. @@ -40,13 +42,16 @@ to copy and use the rest of the PostgreSQL. Why Embedded <Acronym>SQL</Acronym>? -Embedded SQL has some small advantages over other ways to handle SQL +Embedded SQL has some small advantages over other ways +to handle SQL queries. It takes care of all the tedious moving of information to and -from variables in your C program. Many RDBMS packages +from variables in your C program. +Many RDBMS packages support this embedded language. There is an ANSI-standard describing how the embedded language should -work. ecpg was designed to meet this standard as much as possible. So it is +work. ecpg was designed to meet this standard +as much as possible. So it is possible to port programs with embedded SQL written for other RDBMS packages to Postgres and thus promoting the spirit of free @@ -56,28 +61,36 @@ software. The Concept -You write your program in C with some special SQL things. -For declaring variables that can be used in SQL statements you need to +You write your program in C with some +special SQL things. +For declaring variables that can be used in +SQL statements you need to put them in a special declare section. You use a special syntax for the SQL queries. -Before compiling you run the file through the embedded SQL C -preprocessor and it converts the SQL statements you used to function +Before compiling you run the file through +the embedded SQL C +preprocessor and it converts the SQL statements you used +to function calls with the variables used as arguments. Both variables that are used -as input to the SQL statements and variables that will contain the +as input to the SQL statements and variables that will +contain the result are passed. Then you compile and at link time you link with a special library that contains the functions used. These functions (actually it is mostly one single function) fetches the information from the arguments, performs -the SQL query using the ordinary interface (libpq) and puts back +the SQL query using the ordinary interface +(libpq) and puts back the result in the arguments dedicated for output. -Then you run your program and when the control arrives to the SQL -statement the SQL statement is performed against the database and you +Then you run your program and when the control arrives to +the SQL +statement the SQL statement is performed against +the database and you can continue with the result. @@ -91,14 +104,16 @@ This section describes how to use the egpc tool. Preprocessor <Para> -The preprocessor is called <Application>ecpg</Application>. After installation it resides in +The preprocessor is called <Application>ecpg</Application>. +After installation it resides in the <ProductName>Postgres</ProductName> <FileName>bin/</FileName> directory. <Sect2> <Title>Library <Para> -The <Application>ecpg</Application> library is called <FileName>libecpg.a</FileName> or +The <Application>ecpg</Application> library is called +<FileName>libecpg.a</FileName> or <FileName>libecpg.so</FileName>. Additionally, the library uses the <FileName>libpq</FileName> library for communication to the <ProductName>Postgres</ProductName> server so you will @@ -108,42 +123,42 @@ have to link your program with <Parameter>-lecpg -lpq</Parameter>. The library has some methods that are "hidden" but that could prove very useful sometime. -<VariableList> -<VarListEntry> -<Term>ECPGdebug(int, FILE *stream)</Term> -<ListItem> -<Para> -If this is called, with the first argument non-zero, then debuglogging is turned -on. Debuglogging is done on <Function>stream</Function>. Most <Acronym>SQL</Acronym> statement logs its -arguments and result. - -<Para> -The most important one (<Function>ECPGdo</Function>) that is called on all <Acronym>SQL</Acronym> -statements except <Command>EXEC SQL COMMIT</Command>, <Command>EXEC SQL ROLLBACK</Command>, -<Command>EXEC SQL CONNECT</Command> logs both its expanded string, i.e. the string +<itemizedlist> +<listitem> +<para> +<function>ECPGdebug(int <replaceable class="parameter">on</replaceable>, FILE *<replaceable class="parameter">stream</replaceable>)</function> +turns on debug logging if called with the first argument non-zero. +Debug logging is done on <replaceable class="parameter">stream</replaceable>. + Most <Acronym>SQL</Acronym> statement logs its arguments and result. + +<Para> +The most important one (<Function>ECPGdo</Function>) +that is called on all <Acronym>SQL</Acronym> +statements except <Command>EXEC SQL COMMIT</Command>, +<Command>EXEC SQL ROLLBACK</Command>, +<Command>EXEC SQL CONNECT</Command> logs both its expanded string, + i.e. the string with all the input variables inserted, and the result from the -<ProductName>Postgres</ProductName> server. This can be very useful when searching for errors +<ProductName>Postgres</ProductName> server. + This can be very useful when searching for errors in your <Acronym>SQL</Acronym> statements. </Para> </ListItem> -</VarListEntry> -<VarListEntry> -<Term>ECPGstatus()</Term> -<ListItem> -<Para> +<listitem> +<para> +<function>ECPGstatus()</function> This method returns TRUE if we are connected to a database and FALSE if not. </Para> </ListItem> -</VarListEntry> -</VariableList> +</itemizedlist> <Sect2> <Title>Error handling <Para> -To be able to detect errors from the <ProductName>Postgres</ProductName> server you include a line -like +To be able to detect errors from the <ProductName>Postgres</ProductName> +server you include a line like <ProgramListing> exec sql include sqlca; </ProgramListing> @@ -160,8 +175,10 @@ struct sqlca { </ProgramListing> <Para> -If an error occured in the last <Acronym>SQL</Acronym> statement then <Parameter>sqlca.sqlcode</Parameter> -will be non-zero. If <Parameter>sqlca.sqlcode</Parameter> is less that 0 then this is +If an error occured in the last <Acronym>SQL</Acronym> statement +then <Parameter>sqlca.sqlcode</Parameter> +will be non-zero. If <Parameter>sqlca.sqlcode</Parameter> is less that 0 + then this is some kind of serious error, like the database definition does not match the query given. If it is bigger than 0 then this is a normal error like the table did not contain the requested row. @@ -209,7 +226,8 @@ The preprocessor has goofed up and generated some incorrect code. <Term>-1, Error starting transaction line %d.</Term> <ListItem> <Para> -<ProductName>Postgres</ProductName> signalled to us that we cannot open the connection. +<ProductName>Postgres</ProductName> signalled to us that we cannot open +the connection. </Para> </ListItem> </VarListEntry> @@ -218,7 +236,8 @@ The preprocessor has goofed up and generated some incorrect code. <Term>-1, Postgres error: %s line %d.</Term> <ListItem> <Para> -Some <ProductName>Postgres</ProductName> error. The message contains the error message from the +Some <ProductName>Postgres</ProductName> error. +The message contains the error message from the <ProductName>Postgres</ProductName> backend. </Para> </ListItem> @@ -238,8 +257,8 @@ be found or we have gone through the cursor. <Term>-1, To many matches line %d.</Term> <ListItem> <Para> -This means that the query has returned several lines. The <Command>SELECT</Command> -you made probably was not unique. +This means that the query has returned several lines. +The <Command>SELECT</Command> you made probably was not unique. </Para> </ListItem> </VarListEntry> @@ -249,8 +268,9 @@ you made probably was not unique. <ListItem> <Para> This means that the host variable is of an <Type>int</Type> type and the field -in the <ProductName>Postgres</ProductName> database is of another type and contains a value that -cannot be interpreted as an <Type>int</Type>. The library uses <Function>strtol</Function> +in the <ProductName>Postgres</ProductName> database is of another type and +contains a value that cannot be interpreted as an <Type>int</Type>. +The library uses <Function>strtol</Function> for this conversion. </Para> </ListItem> @@ -261,7 +281,8 @@ for this conversion. <ListItem> <Para> This means that the host variable is of an <Type>unsigned int</Type> type and -the field in the <ProductName>Postgres</ProductName> database is of another type and contains a +the field in the <ProductName>Postgres</ProductName> database is of another +type and contains a value that cannot be interpreted as an <Type>unsigned int</Type>. The library uses <Function>strtoul</Function> for this conversion. </Para> @@ -273,7 +294,8 @@ uses <Function>strtoul</Function> for this conversion. <ListItem> <Para> This means that the host variable is of an <Type>float</Type> type and -the field in the <ProductName>Postgres</ProductName> database is of another type and contains a +the field in the <ProductName>Postgres</ProductName> database is of another +type and contains a value that cannot be interpreted as an <Type>float</Type>. The library uses <Function>strtod</Function> for this conversion. </Para> @@ -284,7 +306,8 @@ uses <Function>strtod</Function> for this conversion. <Term>-1, Too few arguments line %d.</Term> <ListItem> <Para> -This means that <ProductName>Postgres</ProductName> has returned more records than we have +This means that <ProductName>Postgres</ProductName> has returned more records +than we have matching variables. Perhaps you have forgotten a couple of the host variables in the <Command>INTO :var1,:var2</Command>-list. </Para> @@ -295,7 +318,8 @@ variables in the <Command>INTO :var1,:var2</Command>-list. <Term>-1, Too many arguments line %d.</Term> <ListItem> <Para> -This means that <ProductName>Postgres</ProductName> has returned fewer records than we have +This means that <ProductName>Postgres</ProductName> has returned fewer records +than we have host variables. Perhaps you have to many host variables in the <Command>INTO :var1,:var2</Command>-list. </Para> @@ -326,8 +350,10 @@ and why is explained in the message. <Term>-1, Postgres error line %d.</Term> <ListItem> <Para> -<ProductName>Postgres</ProductName> returns something that the library does not know how to -handle. This is probably because the version of <ProductName>Postgres</ProductName> does not +<ProductName>Postgres</ProductName> returns something that the library does +not know how to +handle. This is probably because the version of +<ProductName>Postgres</ProductName> does not match the version of the <Application>ecpg</Application> library. </Para> </ListItem> @@ -337,8 +363,10 @@ match the version of the <Application>ecpg</Application> library. <Term>-1, Error committing line %d.</Term> <ListItem> <Para> -Error during <Command>COMMIT</Command>. <Command>EXEC SQL COMMIT</Command> is translated to an -<Command>end</Command> operation in <ProductName>Postgres</ProductName> and that is the operation that could +Error during <Command>COMMIT</Command>. <Command>EXEC SQL COMMIT</Command> +is translated to an +<Command>end</Command> operation in <ProductName>Postgres</ProductName> +and that is the operation that could not be performed. </Para> </ListItem> @@ -348,8 +376,10 @@ not be performed. <Term>-1, Error rolling back line %d.</Term> <ListItem> <Para> -Error during <Command>ROLLBACK</Command>. <Command>EXEC SQL ROLLBACK</Command> is translated to -an <Command>abort</Command> operation in <ProductName>Postgres</ProductName> and that is the operation that +Error during <Command>ROLLBACK</Command>. +<Command>EXEC SQL ROLLBACK</Command> is translated to +an <Command>abort</Command> operation in <ProductName>Postgres</ProductName> +and that is the operation that could not be performed. </Para> </ListItem> @@ -398,27 +428,31 @@ that effort can not justify the performance gained. <Title>Porting From Other <Acronym>RDBMS</Acronym> Packages -To be written by persons that knows the different RDBMS packages and that +To be written by someone who knows the different +RDBMS packages and who actually does port something... Installation -Since version 0.5 ecpg is distributed together with Postgres. So you +Since version 0.5 ecpg is distributed +together with Postgres. So you should get your precompiler, libraries and header files compiled and -installed on the fly. +installed by default as a part of your installation. For the Developer -This section is for those that wants to develop the ecpg interface. It +This section is for those who want to develop the +ecpg interface. It describes how the things work. The ambition is to make this section contain things for those that want to have a look inside and the section on How to use it should be enough for all normal questions. -So, read this before looking at the internals of the ecpg. If +So, read this before looking at the internals of the +ecpg. If you are not interested in how it really works, skip this section. @@ -433,7 +467,8 @@ This version the preprocessor has some flaws: The PQ interface, and most of all the PQexec function, that is used by -the ecpg relies on that the request is built up as a string. In some +the ecpg relies on that the request is built +up as a string. In some cases, like when the data contains the null character, this will be a serious problem. @@ -534,8 +569,8 @@ DESCRIPTOR statement will be ignored. To set up a database you need a few scripts with table definitions and other configuration parameters. If you have these scripts for an old -database you would like to just apply them to get a Postgres database -that works in the same way. +database you would like to just apply them to get a +Postgres database that works in the same way. To set up a database you need a few scripts with table definitions and @@ -562,8 +597,8 @@ everything to the output without looking at it further. When it comes to an EXEC SQL statements it interviens and -changes them depending on what iit is. The EXEC SQL statement can -be one of these: +changes them depending on what iit is. +The EXEC SQL statement can be one of these: @@ -682,20 +717,23 @@ ECPGrollback(__LINE__); Other SQL statements are other statements that start with -exec sql and ends with ;. Everything inbetween is treated +exec sql and ends with ;. +Everything inbetween is treated as an SQL statement and parsed for variable substitution. Variable substitution occur when a symbol starts with a colon -(:). Then a variable with that name is found among the variables +(:). +Then a variable with that name is found among the variables that were previously declared within a declare section and depending on -whether or not the SQL statements knows it to be a variable for input or +whether or not the SQL statements knows it to be +a variable for input or output the pointers to the variables are written to the output to allow for access by the function. -For every variable that is part of the SQL request the function gets -another five arguments. +For every variable that is part of the SQL request +the function gets another five arguments: The type as a special symbol @@ -776,7 +814,8 @@ This is a line number for the original line used in error messages only. A string -This is the SQL request that is to be issued. This request is modified +This is the SQL request that is to be issued. +This request is modified by the input variables, i.e. the variables that where not known at compile time but are to be entered in the request. Where the variables should go the string contains ;. @@ -824,7 +863,8 @@ An enum telling that there are no more variables. -All the SQL statements are performed in one transaction unless you issue +All the SQL statements are performed in one transaction +unless you issue a commit transaction. This works so that the first transaction or the first after a commit or rollback always begins a transaction. diff --git a/doc/src/sgml/libpgtcl.sgml b/doc/src/sgml/libpgtcl.sgml index 245043d586..ed6758be9b 100644 --- a/doc/src/sgml/libpgtcl.sgml +++ b/doc/src/sgml/libpgtcl.sgml @@ -165,14 +165,13 @@ proc getDBs { {host "localhost"} {port "5432"} } { 1997-12-24 +pg_connect -conninfo connectOptions pg_connect dbName -host hostName -port portNumber -tty pqtty -options optionalBackendArgs - -pg_connect -conninfo connectOptions @@ -438,6 +437,8 @@ where the optname is usable as an option in pg_connect -conninfo. Description + + pg_conndefaults returns info about the connection options available in pg_connect -conninfo and the current default value for each option. diff --git a/doc/src/sgml/libpq++.sgml b/doc/src/sgml/libpq++.sgml new file mode 100644 index 0000000000..8e98cc1f79 --- /dev/null +++ b/doc/src/sgml/libpq++.sgml @@ -0,0 +1,584 @@ + +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. + + +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 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. + + +Control and Initialization + + + + +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. + + + + +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: + + + + +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. + + + + + + +Refer to the SET SQL command +for information on correct values for these environment variables. + + + +Database Connection Functions + + + + +Database Environment Class: <classname>PGenv</classname> + + +The database environment class provides C++ objects for manipulating the +above environment variables: + + + + +PGenv +creates an environment for the running program. + + +PGenv() +PGenv(char* auth, char* host, char* port, char* option, char* tty) + + +The first form of this object's constructor sets up the defaults for +the program from the environment variables listed above. +The second allows the programmer to hardcode the values into the program. +The values of the second form relate directly to the environment variables +above. + + + + +Database Class: <classname>PGdatabase</classname> + + +The database class is a provides C++ objects that have a connection +to a backend server. To create such an object one first need +the apropriate environment for the backend to access. +The following constructors deal with making a connection to a backend +server from a C++ program. + + + + +PGdatabase +makes a new connection to a backend database server. + +PGdatabase(PGenv *env, char *dbName) + +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 method. + + + +status +returns the status of the PGdatabase object. + +ConnStatus PGdatabase::status() + + +The following values are allowed: + + +CONNECTION_OK + +CONNECTION_BAD + + + + + +Query Execution Functions + + + + + +PGdatabase::exec +submits a query to Postgres +and returns result status. In case of an error +PGdatabase::errormessage +can be used to get more information on the error. + +void ExecStatusType PGdatabase::exec(char *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 + + + + + +If the result status is PGRES_TUPLES_OK, then the following routines can +be used to retrieve the tuples returned by the query. + + + + +PGdatabase::ntuples +returns the number of tuples (instances) in the query result. + +int PGdatabase::ntuples() + + + + +PGdatabase::nfields +returns the number of fields (attributes) in the query result. + +int PGdatabase::nfields() + + + + +PGdatabase::fieldname +returns the field (attribute) name associated with the given field index. +Field indices start at zero. + +char* PGdatabase::fieldname(int field_index) + + + + +PGdatabase::fieldnum +returns the field (attribute) index associated with the given field name. + +int PGdatabase::fieldnum(char* field_name) + + + + +PGdatabase::fieldtype +returns the field type of associated with the given field index or name. +The integer returned is an internal coding of the type. Field indices start +at zero. + +Oid PGdatabase::fieldtype(int field_index) +Oid PGdatabase::fieldtype(char* field_name) + + + + +PGdatabase::fieldsize +returns the size in bytes of the field associated with the given field +index or name. If the size returned is -1, the field is a variable length +field. Field indices start at zero. + +int2 PGdatabase::fieldsize(int field_index) +int2 PGdatabase::fieldsize(char* field_name) + + + + +PGdatabase::getvalue +returns the field (attribute) value. For most queries, the values +returned by +PGdatabase::getvalue +is a null-terminated ASCII string representation +of the attribute value. If the query was a result of a +BINARY +cursor, then the values returned by +PGdatabase::getvalue +is the binary representation of the type in the internal format of the +backend server. It is the programmer's responsibility to cast and +convert the data to the correct C++ type. The value return by +PGdatabase::getvalue +points to storage that is part of the PGdatabase structure. + One must +explicitly copy the value into other storage if it is to be used past +the next query. + +char* PGdatabase::getvalue(int tup_num, int field_index) +char* PGdatabase::getvalue(int tup_num, char* field_name) + + + + +PGdatabase::getlength +returns the length of a field (attribute) in bytes. If the field +is a struct varlena, +the length returned here does +not +include the size field of the varlena, +i.e., it is 4 bytes less. + +int PGdatabase::getlength(int tup_num, int field_index) +int PGdatabase::getlength(int tup_num, char* field_name) + + + + +PGdatabase::printtuples +prints out all the tuples and, optionally, the attribute names to the +specified output stream. + +void PGdatabase::printtuples( + FILE* fout, /* output stream */ + int printAttName,/* print attribute names or not*/ + int terseOutput, /* delimiter bars or not?*/ + int width /* width of column, variable width if 0*/ + ); + + + + + +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 + + +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 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 + + +The query buffer is 8192 bytes long, and queries over that length will +be silently truncated. + + +The PGlobj class is largely untested. Use with caution. + + \ No newline at end of file diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index a78fdb6f38..c38ef7cb29 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -51,7 +51,7 @@ header file libpq-fe.h and must link with the PQsetdbLogin Makes a new connection to a backend. - + PGconn *PQsetdbLogin(const char *pghost, const char *pgport, const char *pgoptions, @@ -59,7 +59,7 @@ PGconn *PQsetdbLogin(const char *pghost, const char *dbName, const char *login, const char *pwd) - + If any argument is NULL, then the corresponding environment variable (see "Environment Variables" section) is checked. If the environment variable @@ -73,13 +73,13 @@ PGconn *PQsetdbLogin(const char *pghost, PQsetdb Makes a new connection to a backend. - + PGconn *PQsetdb(char *pghost, char *pgport, char *pgoptions, char *pgtty, char *dbName) - + This is a macro that calls PQsetdbLogin() with null pointers for the login and pwd parameters. It is provided primarily for backward compatibility with old programs. @@ -90,9 +90,9 @@ PGconn *PQsetdb(char *pghost, PQconnectdb Makes a new connection to a backend. - + PGconn *PQconnectdb(const char *conninfo) - + This routine opens a new database connection using parameters taken from a string. Unlike PQsetdbLogin(), the parameter set can be extended without changing the function signature, so use @@ -162,7 +162,7 @@ default values for unspecified options. PQconndefaults Returns the default connection options. - + PQconninfoOption *PQconndefaults(void) struct PQconninfoOption @@ -181,7 +181,7 @@ struct PQconninfoOption int dispsize; /* Field size in characters for dialog */ }; - + Returns the address of the connection options structure. This may be used to determine all possible PQconnectdb options and their current default values. The return value points to an array of @@ -197,9 +197,9 @@ struct PQconninfoOption PQfinish Close the connection to the backend. Also frees memory used by the PGconn object. - + void PQfinish(PGconn *conn) - + Note that even if the backend connection attempt fails (as indicated by PQstatus), the application should call PQfinish to free the memory used by the PGconn object. @@ -211,9 +211,9 @@ The PGconn pointer should not be used after PQfinish has been called. PQreset Reset the communication port with the backend. - + void PQreset(PGconn *conn) - + This function will close the connection to the backend and attempt to reestablish a new connection to the same postmaster, using all the same @@ -240,9 +240,9 @@ soon.) PQdb Returns the database name of the connection. - + char *PQdb(PGconn *conn) - + PQdb and the next several functions return the values established at connection. These values are fixed for the life of the PGconn object. @@ -253,9 +253,9 @@ object. PQuser Returns the user name of the connection. - + char *PQuser(PGconn *conn) - + @@ -263,9 +263,9 @@ char *PQuser(PGconn *conn) PQpass Returns the password of the connection. - + char *PQpass(PGconn *conn) - + @@ -273,9 +273,9 @@ char *PQpass(PGconn *conn) PQhost Returns the server host name of the connection. - + char *PQhost(PGconn *conn) - + @@ -283,9 +283,9 @@ char *PQhost(PGconn *conn) PQport Returns the port of the connection. - + char *PQport(PGconn *conn) - + @@ -293,9 +293,9 @@ char *PQport(PGconn *conn) PQtty Returns the debug tty of the connection. - + char *PQtty(PGconn *conn) - + @@ -303,9 +303,9 @@ char *PQtty(PGconn *conn) PQoptions Returns the backend options used in the connection. - + char *PQoptions(PGconn *conn) - + @@ -314,10 +314,11 @@ char *PQoptions(PGconn *conn) PQstatus Returns the status of the connection. The status can be CONNECTION_OK or CONNECTION_BAD. - + ConnStatusType *PQstatus(PGconn *conn) - - + + + A failed connection attempt is signaled by status CONNECTION_BAD. Ordinarily, an OK status will remain so until PQfinish, but a communications failure might result in the status changing to @@ -330,10 +331,11 @@ try to recover by calling PQreset. PQerrorMessage Returns the error message most recently generated by an operation on the connection. - + char *PQerrorMessage(PGconn* conn); - - + + + Nearly all libpq functions will set PQerrorMessage if they fail. Note that by libpq convention, a non-empty PQerrorMessage will include a trailing newline. @@ -344,9 +346,9 @@ include a trailing newline. PQbackendPID Returns the process ID of the backend server handling this connection. - + int PQbackendPID(PGconn *conn); - + The backend PID is useful for debugging purposes and for comparison to NOTIFY messages (which include the PID of the notifying backend). Note that the PID belongs to a process executing on the database @@ -371,10 +373,10 @@ SQL queries and commands. PQexec Submit a query to Postgres and wait for the result. - + PGresult *PQexec(PGconn *conn, const char *query); - + Returns a PGresult pointer or possibly a NULL pointer. A non-NULL pointer will generally be returned except in out-of-memory conditions or serious errors such as inability @@ -405,7 +407,7 @@ soon.) PQresultStatus Returns the result status of the query. PQresultStatus can return one of the following values: - + PGRES_EMPTY_QUERY, PGRES_COMMAND_OK, /* the query was a command returning no data */ PGRES_TUPLES_OK, /* the query successfully returned tuples */ @@ -414,7 +416,7 @@ PGRES_COPY_IN, /* Copy In (to server) data transfer started */ PGRES_BAD_RESPONSE, /* an unexpected response was received */ PGRES_NONFATAL_ERROR, PGRES_FATAL_ERROR - + If the result status is PGRES_TUPLES_OK, then the routines described below can be used to retrieve the tuples returned by the query. Note that a SELECT that @@ -428,9 +430,9 @@ PGRES_FATAL_ERROR PQresultErrorMessage returns the error message associated with the query, or an empty string if there was no error. - + const char *PQresultErrorMessage(PGresult *res); - + Immediately following a PQexec or PQgetResult call, PQerrorMessage (on the connection) will return the same string as PQresultErrorMessage (on the result). However, a PGresult will retain its error message @@ -446,9 +448,9 @@ when you want to know the status from the latest operation on the connection. PQntuples Returns the number of tuples (instances) in the query result. - + int PQntuples(PGresult *res); - + @@ -457,9 +459,9 @@ int PQntuples(PGresult *res); PQnfields Returns the number of fields (attributes) in each tuple of the query result. - + int PQnfields(PGresult *res); - + @@ -468,9 +470,9 @@ int PQnfields(PGresult *res); PQbinaryTuples Returns 1 if the PGresult contains binary tuple data, 0 if it contains ASCII data. - + int PQbinaryTuples(PGresult *res); - + Currently, binary tuple data can only be returned by a query that extracts data from a BINARY cursor. @@ -479,12 +481,12 @@ extracts data from a BINARY cursor. PQfname - Returns the field (attribute) name associated with the given field index. Field indices - start at 0. - + Returns the field (attribute) name associated with the given field index. + Field indices start at 0. + char *PQfname(PGresult *res, int field_index); - + @@ -493,11 +495,12 @@ char *PQfname(PGresult *res, PQfnumber Returns the field (attribute) index associated with the given field name. - + int PQfnumber(PGresult *res, char* field_name); - - + + + -1 is returned if the given name does not match any field. @@ -508,10 +511,10 @@ int PQfnumber(PGresult *res, given field index. The integer returned is an internal coding of the type. Field indices start at 0. - + Oid PQftype(PGresult *res, int field_num); - + @@ -522,10 +525,10 @@ Oid PQftype(PGresult *res, associated with the given field index. If the size returned is -1, the field is a variable length field. Field indices start at 0. - + int PQfsize(PGresult *res, int field_index); - + @@ -535,10 +538,10 @@ int PQfsize(PGresult *res, Returns the type-specific modification data of the field associated with the given field index. Field indices start at 0. - + int PQfmod(PGresult *res, int field_index); - + @@ -548,11 +551,11 @@ int PQfmod(PGresult *res, Returns a single field (attribute) value of one tuple of a PGresult. Tuple and field indices start at 0. - + char* PQgetvalue(PGresult *res, int tup_num, int field_num); - + For most queries, the value returned by PQgetvalue is a null-terminated ASCII string representation of the attribute value. If the query extracted data from @@ -574,11 +577,11 @@ char* PQgetvalue(PGresult *res, PQgetisnull Tests a field for a NULL entry. Tuple and field indices start at 0. - + int PQgetisnull(PGresult *res, int tup_num, int field_num); - + This function returns 1 if the field contains a NULL, 0 if it contains a non-null value. (Note that PQgetvalue will return an empty string, not a null pointer, for a NULL @@ -592,11 +595,11 @@ int PQgetisnull(PGresult *res, Returns the length of a field (attribute) in bytes. Tuple and field indices start at 0. - + int PQgetlength(PGresult *res, int tup_num, int field_num); - + This is the actual data length for the particular data value, whereas PQfsize shows the allocated space for all entries in this column. @@ -612,9 +615,9 @@ If the field is a struct PQcmdStatus Returns the command status string from the SQL command that generated the PGresult. - + char *PQcmdStatus(PGresult *res); - + @@ -622,9 +625,9 @@ char *PQcmdStatus(PGresult *res); PQcmdTuples Returns the number of rows affected by the SQL command. - + const char *PQcmdTuples(PGresult *res); - + If the SQL command that generated the PGresult was INSERT, UPDATE or DELETE, this returns a string containing the number of rows affected. If the @@ -638,9 +641,9 @@ const char *PQcmdTuples(PGresult *res); Returns a string with the object id of the tuple inserted, if the SQL command was an INSERT. Otherwise, returns an empty string. - + char* PQoidStatus(PGresult *res); - + @@ -649,7 +652,7 @@ char* PQoidStatus(PGresult *res); PQprint Prints out all the tuples and, optionally, the attribute names to the specified output stream. - + void PQprint(FILE* fout, /* output stream */ PGresult* res, PQprintOpt* po); @@ -667,7 +670,7 @@ struct _PQprintOpt char *caption; /* HTML <caption> */ char **fieldName; /* null terminated array of replacement field names */ }; - + This function is intended to replace PQprintTuples(), which is now obsolete. The psql program uses PQprint() to display query results. @@ -679,13 +682,13 @@ struct _PQprintOpt PQprintTuples Prints out all the tuples and, optionally, the attribute names to the specified output stream. - + void PQprintTuples(PGresult* res, FILE* fout, /* output stream */ int printAttName,/* print attribute names or not*/ int terseOutput, /* delimiter bars or not?*/ int width); /* width of column, variable width if 0*/ - + @@ -694,14 +697,14 @@ void PQprintTuples(PGresult* res, PQdisplayTuples Prints out all the tuples and, optionally, the attribute names to the specified output stream. - + void PQdisplayTuples(PGresult* res, FILE* fout, /* output stream */ int fillAlign, /* space fill to align columns */ const char *fieldSep, /* field separator */ int printHeader, /* display headers? */ int quiet); /* suppress print of row count at end */ - + PQdisplayTuples() was intended to supersede PQprintTuples(), and is in turn superseded by PQprint(). @@ -712,9 +715,9 @@ void PQdisplayTuples(PGresult* res, Frees the storage associated with the PGresult. Every query result should be freed via PQclear when it is no longer needed. - + void PQclear(PQresult *res); - + You can keep a PGresult object around for as long as you need it; it does not go away when you issue a new query, nor even if you close the connection. To get rid of it, @@ -727,9 +730,9 @@ void PQclear(PQresult *res); PQmakeEmptyPGresult Constructs an empty PGresult object with the given status. - + PGresult* PQmakeEmptyPGresult(PGconn *conn, ExecStatusType status); - + This is libpq's internal routine to allocate and initialize an empty PGresult object. It is exported because some applications find it useful to generate result objects (particularly objects with error @@ -791,10 +794,10 @@ PQgetResult. waiting for the result(s). TRUE is returned if the query was successfully dispatched, FALSE if not (in which case, use PQerrorMessage to get more information about the failure). - + int PQsendQuery(PGconn *conn, const char *query); - + After successfully calling PQsendQuery, call PQgetResult one or more times to obtain the query results. PQsendQuery may not be called again (on the same connection) until PQgetResult has returned NULL, @@ -808,9 +811,9 @@ int PQsendQuery(PGconn *conn, Wait for the next result from a prior PQsendQuery, and return it. NULL is returned when the query is complete and there will be no more results. - + PGresult *PQgetResult(PGconn *conn); - + PQgetResult must be called repeatedly until it returns NULL, indicating that the query is done. (If called when no query is active, PQgetResult will just return NULL at once.) @@ -842,9 +845,9 @@ functions: PQconsumeInput If input is available from the backend, consume it. - + int PQconsumeInput(PGconn *conn); - + PQconsumeInput normally returns 1 indicating "no error", but returns 0 if there was some kind of trouble (in which case PQerrorMessage is set). Note that the result does not say whether any input data @@ -866,9 +869,9 @@ has changed. Returns TRUE if a query is busy, that is, PQgetResult would block waiting for input. A FALSE return indicates that PQgetResult can be called with assurance of not blocking. - + int PQisBusy(PGconn *conn); - + PQisBusy will not itself attempt to read data from the backend; therefore PQconsumeInput must be invoked first, or the busy state will never end. @@ -881,9 +884,9 @@ int PQisBusy(PGconn *conn); Obtain the file descriptor number for the backend connection socket. A valid descriptor will be >= 0; a result of -1 indicates that no backend connection is currently open. - + int PQsocket(PGconn *conn); - + PQsocket should be used to obtain the backend socket descriptor in preparation for executing select(2). This allows an application to wait for either backend responses or other conditions. @@ -919,9 +922,9 @@ a query that is still being processed by the backend. PQrequestCancel Request that Postgres abandon processing of the current query. - + int PQrequestCancel(PGconn *conn); - + The return value is TRUE if the cancel request was successfully dispatched, FALSE if not. (If not, PQerrorMessage tells why not.) Successful dispatch is no guarantee that the request will have any @@ -963,7 +966,7 @@ or the backend is not currently processing a query. calls to the backend. This is a trapdoor into system internals and can be a potential security hole. Most users will not need this feature. - + PGresult* PQfn(PGconn* conn, int fnid, int *result_buf, @@ -971,7 +974,7 @@ PGresult* PQfn(PGconn* conn, int result_is_int, PQArgBlock *args, int nargs); - + The fnid argument is the object identifier of the function to be executed. result_buf is the buffer in which @@ -982,7 +985,7 @@ PGresult* PQfn(PGconn* conn, value, than result_is_int should be set to 1; otherwise it should be set to 0. args and nargs specify the arguments to the function. - + typedef struct { int len; int isint; @@ -991,7 +994,7 @@ typedef struct { int integer; } u; } PQArgBlock; - + PQfn always returns a valid PGresult*. The resultStatus should be checked before the result is used. The caller is responsible for freeing the PGresult with PQclear when it is no longer needed. @@ -1032,9 +1035,9 @@ messages can be detected by calling PQnotifies(). there are no pending notifications. Once a notification is returned from PQnotifies, it is considered handled and will be removed from the list of notifications. - + PGnotify* PQnotifies(PGconn *conn); - + After processing a PGnotify object returned by PQnotifies, be sure to free it with free() to avoid a memory leak. @@ -1087,11 +1090,11 @@ processing of the query. Reads a newline-terminated line of characters (transmitted by the backend server) into a buffer string of size length. - + int PQgetline(PGconn *conn, char *string, int length) - + Like 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. @@ -1121,11 +1124,11 @@ contains routines that correctly handle the copy protocol. Reads a newline-terminated line of characters (transmitted by the backend server) into a buffer without blocking. - + int PQgetlineAsync(PGconn *conn, char *buffer, int bufsize) - + This routine is similar to PQgetline, but it can be used by applications that must read COPY data asynchronously, that is without blocking. Having issued the COPY command and gotten a PGRES_COPY_OUT response, the @@ -1156,10 +1159,10 @@ actually available.) PQputline Sends a null-terminated string to the backend server. Returns 0 if OK, EOF if unable to send the string. - + int PQputline(PGconn *conn, char *string); - + Note the application must explicitly send the two characters "\." on a final line to indicate to the backend that it has finished sending its data. @@ -1171,11 +1174,11 @@ has finished sending its data. PQputnbytes Sends a non-null-terminated string to the backend server. Returns 0 if OK, EOF if unable to send the string. - + int PQputnbytes(PGconn *conn, const char *buffer, int nbytes); - + This is exactly like PQputline, except that the data buffer need not be null-terminated since the number of bytes to send is specified directly. @@ -1196,9 +1199,9 @@ specified directly. receive the next query. The return value is 0 on successful completion, nonzero otherwise. - + int PQendcopy(PGconn *conn); - + As an example: @@ -1244,10 +1247,10 @@ SQL command in the query string. PQtrace Enable tracing of the frontend/backend communication to a debugging file stream. - + void PQtrace(PGconn *conn FILE *debug_port) - + @@ -1255,9 +1258,9 @@ void PQtrace(PGconn *conn PQuntrace Disable tracing started by PQtrace - + void PQuntrace(PGconn *conn) - + @@ -1275,11 +1278,11 @@ void PQuntrace(PGconn *conn) PQsetNoticeProcessor Control reporting of notice and warning messages generated by libpq. - + void PQsetNoticeProcessor (PGconn * conn, void (*noticeProcessor) (void * arg, const char * message), void * arg) - + @@ -1330,9 +1333,9 @@ routines no longer have any effect and should not be used. user name is not the same as value of the USER environment variable or the user's entry in /etc/passwd. - + char *fe_getauthname(char* errorMessage) - + @@ -1343,10 +1346,10 @@ char *fe_getauthname(char* errorMessage) service name rather than its compiled-in default. This value is typically taken from a command-line switch. - + void fe_setauthsvc(char *name, char* errorMessage) - + Any error messages from the authentication attempts are returned in the errorMessage argument. @@ -1356,7 +1359,7 @@ void fe_setauthsvc(char *name, - + Environment Variables @@ -1383,7 +1386,8 @@ backend. -PGDATABASE sets the default Postgres database name. +PGDATABASE sets the default +Postgres database name. @@ -1400,9 +1404,11 @@ sets the password used if the backend demands password authentication. -PGREALM sets the Kerberos realm to use with Postgres, +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 +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 @@ -1411,12 +1417,14 @@ sets the password used if the backend demands password authentication. -PGOPTIONS sets additional runtime options for the Postgres 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. +PGTTY sets the file or tty on which debugging +messages from the backend server are displayed. @@ -1498,115 +1506,115 @@ for information on correct values for these environment variables. - /* - * testlibpq.c - * Test the C version of LIBPQ, the Postgres frontend library. - * - * - */ - #include <stdio.h> - #include "libpq-fe.h" - - void - exit_nicely(PGconn* conn) - { - PQfinish(conn); - exit(1); - } - - main() - { - char *pghost, *pgport, *pgoptions, *pgtty; - char* dbName; - int nFields; - int i,j; - - /* FILE *debug; */ - - PGconn* conn; - PGresult* res; - - /* begin, by setting the parameters for a backend connection - if the parameters are null, then the system will try to use - reasonable defaults by looking up environment variables - or, failing that, using hardwired constants */ - pghost = NULL; /* host name of the backend server */ - pgport = NULL; /* port of the backend server */ - pgoptions = NULL; /* special options to start up the backend server */ - pgtty = NULL; /* debugging tty for the backend server */ - dbName = "template1"; - - /* make a connection to the database */ - conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName); - - /* check to see that the backend connection was successfully made */ - if (PQstatus(conn) == CONNECTION_BAD) { - fprintf(stderr,"Connection to database '%s' failed.\n", dbName); - fprintf(stderr,"%s",PQerrorMessage(conn)); - exit_nicely(conn); - } - - /* debug = fopen("/tmp/trace.out","w"); */ - /* PQtrace(conn, debug); */ - - /* start a transaction block */ - - res = PQexec(conn,"BEGIN"); - if (PQresultStatus(res) != PGRES_COMMAND_OK) { - fprintf(stderr,"BEGIN command failed\n"); - PQclear(res); - exit_nicely(conn); - } - /* should PQclear PGresult whenever it is no longer needed to avoid - memory leaks */ - PQclear(res); - - /* fetch instances from the pg_database, the system catalog of databases*/ - res = PQexec(conn,"DECLARE mycursor CURSOR FOR select * from pg_database"); - if (PQresultStatus(res) != PGRES_COMMAND_OK) { - fprintf(stderr,"DECLARE CURSOR command failed\n"); - PQclear(res); - exit_nicely(conn); - } - PQclear(res); - - res = PQexec(conn,"FETCH ALL in mycursor"); - if (PQresultStatus(res) != PGRES_TUPLES_OK) { - fprintf(stderr,"FETCH ALL command didn't return tuples properly\n"); - PQclear(res); - exit_nicely(conn); - } - - /* first, print out the attribute names */ - nFields = PQnfields(res); - for (i=0; i < nFields; i++) { - printf("%-15s",PQfname(res,i)); - } - printf("\n"); - - /* next, print out the instances */ - for (i=0; i < PQntuples(res); i++) { - for (j=0 ; j < nFields; j++) { - printf("%-15s", PQgetvalue(res,i,j)); - } - printf("\n"); - } - - PQclear(res); - - /* close the cursor */ - res = PQexec(conn, "CLOSE mycursor"); - PQclear(res); - - /* end the transaction */ - res = PQexec(conn, "END"); - PQclear(res); - - /* close the connection to the database and cleanup */ - PQfinish(conn); - - /* fclose(debug); */ - } +/* +* testlibpq.c +* Test the C version of LIBPQ, ++ the Postgres frontend library. +* +* +*/ +#include <stdio.h> +#include "libpq-fe.h" + +void +exit_nicely(PGconn* conn) +{ + PQfinish(conn); + exit(1); +} + +main() +{ + char *pghost, *pgport, *pgoptions, *pgtty; + char* dbName; + int nFields; + int i,j; + +/* FILE *debug; */ + + PGconn* conn; + PGresult* res; + + /* begin, by setting the parameters for a backend connection + if the parameters are null, then the system will try to use + reasonable defaults by looking up environment variables + or, failing that, using hardwired constants */ + pghost = NULL; /* host name of the backend server */ + pgport = NULL; /* port of the backend server */ + pgoptions = NULL; /* special options to start up the backend server */ + pgtty = NULL; /* debugging tty for the backend server */ + dbName = "template1"; + + /* make a connection to the database */ + conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName); + + /* check to see that the backend connection was successfully made */ + if (PQstatus(conn) == CONNECTION_BAD) { + fprintf(stderr,"Connection to database '%s' failed.\n", dbName); + fprintf(stderr,"%s",PQerrorMessage(conn)); + exit_nicely(conn); + } + + /* debug = fopen("/tmp/trace.out","w"); */ + /* PQtrace(conn, debug); */ + + /* start a transaction block */ + + res = PQexec(conn,"BEGIN"); + if (PQresultStatus(res) != PGRES_COMMAND_OK) { + fprintf(stderr,"BEGIN command failed\n"); + PQclear(res); + exit_nicely(conn); + } + /* should PQclear PGresult when done to avoid memory leaks */ + PQclear(res); + + /* fetch instances from the pg_database, the system catalog of databases*/ + res = PQexec(conn,"DECLARE mycursor CURSOR FOR select * from pg_database"); + if (PQresultStatus(res) != PGRES_COMMAND_OK) { + fprintf(stderr,"DECLARE CURSOR command failed\n"); + PQclear(res); + exit_nicely(conn); + } + PQclear(res); + + res = PQexec(conn,"FETCH ALL in mycursor"); + if (PQresultStatus(res) != PGRES_TUPLES_OK) { + fprintf(stderr,"FETCH ALL command didn't return tuples properly\n"); + PQclear(res); + exit_nicely(conn); + } + + /* first, print out the attribute names */ + nFields = PQnfields(res); + for (i=0; i < nFields; i++) { + printf("%-15s",PQfname(res,i)); + } + printf("\n"); + + /* next, print out the instances */ + for (i=0; i < PQntuples(res); i++) { + for (j=0 ; j < nFields; j++) { + printf("%-15s", PQgetvalue(res,i,j)); + } + printf("\n"); + } + + PQclear(res); + + /* close the cursor */ + res = PQexec(conn, "CLOSE mycursor"); + PQclear(res); + + /* end the transaction */ + res = PQexec(conn, "END"); + PQclear(res); + + /* close the connection to the database and cleanup */ + PQfinish(conn); + +/* fclose(debug); */ +} @@ -1616,96 +1624,97 @@ for information on correct values for these environment variables. - /* - * testlibpq2.c - * Test of the asynchronous notification interface - * - populate a database with the following: - - CREATE TABLE TBL1 (i int4); - - CREATE TABLE TBL2 (i int4); - - CREATE RULE r1 AS ON INSERT TO TBL1 DO [INSERT INTO TBL2 values (new.i); NOTIFY TBL2]; - - * Then start up this program - * After the program has begun, do - - INSERT INTO TBL1 values (10); - - * - * - */ - #include <stdio.h> - #include "libpq-fe.h" - - void exit_nicely(PGconn* conn) - { - PQfinish(conn); - exit(1); - } - - main() - { - char *pghost, *pgport, *pgoptions, *pgtty; - char* dbName; - int nFields; - int i,j; - - PGconn* conn; - PGresult* res; - PGnotify* notify; - - /* begin, by setting the parameters for a backend connection - if the parameters are null, then the system will try to use - reasonable defaults by looking up environment variables - or, failing that, using hardwired constants */ - pghost = NULL; /* host name of the backend server */ - pgport = NULL; /* port of the backend server */ - pgoptions = NULL; /* special options to start up the backend server */ - pgtty = NULL; /* debugging tty for the backend server */ - dbName = getenv("USER"); /* change this to the name of your test database*/ - - /* make a connection to the database */ - conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName); - - /* check to see that the backend connection was successfully made */ - if (PQstatus(conn) == CONNECTION_BAD) { - fprintf(stderr,"Connection to database '%s' failed.\n", dbName); - fprintf(stderr,"%s",PQerrorMessage(conn)); - exit_nicely(conn); - } - - res = PQexec(conn, "LISTEN TBL2"); - if (PQresultStatus(res) != PGRES_COMMAND_OK) { - fprintf(stderr,"LISTEN command failed\n"); - PQclear(res); - exit_nicely(conn); - } - /* should PQclear PGresult whenever it is no longer needed to avoid - memory leaks */ - PQclear(res); - - while (1) { - /* wait a little bit between checks; - * waiting with select() would be more efficient. - */ - sleep(1); - /* collect any asynchronous backend messages */ - PQconsumeInput(conn); - /* check for asynchronous notify messages */ - while ((notify = PQnotifies(conn)) != NULL) { - fprintf(stderr, - "ASYNC NOTIFY of '%s' from backend pid '%d' received\n", - notify->relname, notify->be_pid); - free(notify); - } - } - - /* close the connection to the database and cleanup */ - PQfinish(conn); - - } +/* + * testlibpq2.c + * Test of the asynchronous notification interface + * + populate a database with the following: + + CREATE TABLE TBL1 (i int4); + + CREATE TABLE TBL2 (i int4); + + CREATE RULE r1 AS ON INSERT TO TBL1 + DO [INSERT INTO TBL2 values (new.i); NOTIFY TBL2]; + +* Then start up this program +* After the program has begun, do + + INSERT INTO TBL1 values (10); + +* +* +*/ +#include <stdio.h> +#include "libpq-fe.h" + +void exit_nicely(PGconn* conn) +{ + PQfinish(conn); + exit(1); +} + +main() +{ + char *pghost, *pgport, *pgoptions, *pgtty; + char* dbName; + int nFields; + int i,j; + + PGconn* conn; + PGresult* res; + PGnotify* notify; + + /* begin, by setting the parameters for a backend connection + if the parameters are null, then the system will try to use + reasonable defaults by looking up environment variables + or, failing that, using hardwired constants */ + pghost = NULL; /* host name of the backend server */ + pgport = NULL; /* port of the backend server */ + pgoptions = NULL; /* special options to start up the backend server */ + pgtty = NULL; /* debugging tty for the backend server */ + dbName = getenv("USER"); /* change this to the name of your test database*/ + + /* make a connection to the database */ + conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName); + + /* check to see that the backend connection was successfully made */ + if (PQstatus(conn) == CONNECTION_BAD) { + fprintf(stderr,"Connection to database '%s' failed.\n", dbName); + fprintf(stderr,"%s",PQerrorMessage(conn)); + exit_nicely(conn); + } + + res = PQexec(conn, "LISTEN TBL2"); + if (PQresultStatus(res) != PGRES_COMMAND_OK) { + fprintf(stderr,"LISTEN command failed\n"); + PQclear(res); + exit_nicely(conn); + } + /* should PQclear PGresult whenever it is no longer needed to avoid + memory leaks */ + PQclear(res); + + while (1) { + /* wait a little bit between checks; + * waiting with select() would be more efficient. + */ + sleep(1); + /* collect any asynchronous backend messages */ + PQconsumeInput(conn); + /* check for asynchronous notify messages */ + while ((notify = PQnotifies(conn)) != NULL) { + fprintf(stderr, + "ASYNC NOTIFY of '%s' from backend pid '%d' received\n", + notify->relname, notify->be_pid); + free(notify); + } + } + + /* close the connection to the database and cleanup */ + PQfinish(conn); + +} @@ -1715,154 +1724,158 @@ for information on correct values for these environment variables. - /* - * testlibpq3.c - * Test the C version of LIBPQ, the Postgres frontend library. - * tests the binary cursor interface - * - * - * - populate a database by doing the following: - - CREATE TABLE test1 (i int4, d float4, p polygon); - - INSERT INTO test1 values (1, 3.567, '(3.0, 4.0, 1.0, 2.0)'::polygon); - - INSERT INTO test1 values (2, 89.05, '(4.0, 3.0, 2.0, 1.0)'::polygon); - - the expected output is: - - tuple 0: got - i = (4 bytes) 1, - d = (4 bytes) 3.567000, - p = (4 bytes) 2 points boundbox = (hi=3.000000/4.000000, lo = 1.000000,2.000000) - tuple 1: got - i = (4 bytes) 2, - d = (4 bytes) 89.050003, - p = (4 bytes) 2 points boundbox = (hi=4.000000/3.000000, lo = 2.000000,1.000000) - - * - */ - #include <stdio.h> - #include "libpq-fe.h" - #include "utils/geo-decls.h" /* for the POLYGON type */ - - void exit_nicely(PGconn* conn) - { - PQfinish(conn); - exit(1); - } - - main() - { - char *pghost, *pgport, *pgoptions, *pgtty; - char* dbName; - int nFields; - int i,j; - int i_fnum, d_fnum, p_fnum; - - PGconn* conn; - PGresult* res; - - /* begin, by setting the parameters for a backend connection - if the parameters are null, then the system will try to use - reasonable defaults by looking up environment variables - or, failing that, using hardwired constants */ - pghost = NULL; /* host name of the backend server */ - pgport = NULL; /* port of the backend server */ - pgoptions = NULL; /* special options to start up the backend server */ - pgtty = NULL; /* debugging tty for the backend server */ - - dbName = getenv("USER"); /* change this to the name of your test database*/ - - /* make a connection to the database */ - conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName); - - /* check to see that the backend connection was successfully made */ - if (PQstatus(conn) == CONNECTION_BAD) { - fprintf(stderr,"Connection to database '%s' failed.\n", dbName); - fprintf(stderr,"%s",PQerrorMessage(conn)); - exit_nicely(conn); - } - - /* start a transaction block */ - res = PQexec(conn,"BEGIN"); - if (PQresultStatus(res) != PGRES_COMMAND_OK) { - fprintf(stderr,"BEGIN command failed\n"); - PQclear(res); - exit_nicely(conn); - } - /* should PQclear PGresult whenever it is no longer needed to avoid - memory leaks */ - PQclear(res); - - /* fetch instances from the pg_database, the system catalog of databases*/ - res = PQexec(conn,"DECLARE mycursor BINARY CURSOR FOR select * from test1"); - if (PQresultStatus(res) != PGRES_COMMAND_OK) { - fprintf(stderr,"DECLARE CURSOR command failed\n"); - PQclear(res); - exit_nicely(conn); - } - PQclear(res); - - res = PQexec(conn,"FETCH ALL in mycursor"); - if (PQresultStatus(res) != PGRES_TUPLES_OK) { - fprintf(stderr,"FETCH ALL command didn't return tuples properly\n"); - PQclear(res); - exit_nicely(conn); - } - - i_fnum = PQfnumber(res,"i"); - d_fnum = PQfnumber(res,"d"); - p_fnum = PQfnumber(res,"p"); - - for (i=0;i<3;i++) { - printf("type[%d] = %d, size[%d] = %d\n", - i, PQftype(res,i), - i, PQfsize(res,i)); - } - for (i=0; i < PQntuples(res); i++) { - int *ival; - float *dval; - int plen; - POLYGON* pval; - /*/ - ival = (int*)PQgetvalue(res,i,i_fnum); - dval = (float*)PQgetvalue(res,i,d_fnum); - plen = PQgetlength(res,i,p_fnum); - - /* plen doesn't include the length field so need to increment by VARHDSZ*/ - pval = (POLYGON*) malloc(plen + VARHDRSZ); - pval->size = plen; - memmove((char*)&pval->npts, PQgetvalue(res,i,p_fnum), plen); - printf("tuple %d: got\n", i); - printf(" i = (%d bytes) %d,\n", - PQgetlength(res,i,i_fnum), *ival); - printf(" d = (%d bytes) %f,\n", - PQgetlength(res,i,d_fnum), *dval); - printf(" p = (%d bytes) %d points boundbox = (hi=%f/%f, lo = %f,%f)\n", - PQgetlength(res,i,d_fnum), - pval->npts, - pval->boundbox.xh, - pval->boundbox.yh, - pval->boundbox.xl, - pval->boundbox.yl); - } - - PQclear(res); - - /* close the cursor */ - res = PQexec(conn, "CLOSE mycursor"); - PQclear(res); - - /* end the transaction */ - res = PQexec(conn, "END"); - PQclear(res); - - /* close the connection to the database and cleanup */ - PQfinish(conn); - - } +/* + * testlibpq3.c + * Test the C version of LIBPQ, + + the Postgres frontend library + * tests the binary cursor interface + * + * + * + populate a database by doing the following: + + CREATE TABLE test1 (i int4, d float4, p polygon); + + INSERT INTO test1 values (1, 3.567, '(3.0, 4.0, 1.0, 2.0)'::polygon); + + INSERT INTO test1 values (2, 89.05, '(4.0, 3.0, 2.0, 1.0)'::polygon); + + the expected output is: + + tuple 0: got + i = (4 bytes) 1, + d = (4 bytes) 3.567000, + p = (4 bytes) 2 points + boundbox = (hi=3.000000/4.000000, lo = 1.000000,2.000000) + tuple 1: got + i = (4 bytes) 2, + d = (4 bytes) 89.050003, + p = (4 bytes) 2 points + boundbox = (hi=4.000000/3.000000, lo = 2.000000,1.000000) + * + */ +#include <stdio.h> +#include "libpq-fe.h" +#include "utils/geo-decls.h" /* for the POLYGON type */ + +void exit_nicely(PGconn* conn) +{ + PQfinish(conn); + exit(1); +} + +main() +{ + char *pghost, *pgport, *pgoptions, *pgtty; + char* dbName; + int nFields; + int i,j; + int i_fnum, d_fnum, p_fnum; + + PGconn* conn; + PGresult* res; + + /* begin, by setting the parameters for a backend connection + if the parameters are null, then the system will try to use + reasonable defaults by looking up environment variables + or, failing that, using hardwired constants */ + pghost = NULL; /* host name of the backend server */ + pgport = NULL; /* port of the backend server */ + pgoptions = NULL; /* special options to start up the backend server */ + pgtty = NULL; /* debugging tty for the backend server */ + + dbName = getenv("USER"); /* change this to the name of your test database*/ + + /* make a connection to the database */ + conn = PQsetdb(pghost, pgport, pgoptions, pgtty, dbName); + + /* check to see that the backend connection was successfully made */ + if (PQstatus(conn) == CONNECTION_BAD) { + fprintf(stderr,"Connection to database '%s' failed.\n", dbName); + fprintf(stderr,"%s",PQerrorMessage(conn)); + exit_nicely(conn); + } + + /* start a transaction block */ + res = PQexec(conn,"BEGIN"); + if (PQresultStatus(res) != PGRES_COMMAND_OK) { + fprintf(stderr,"BEGIN command failed\n"); + PQclear(res); + exit_nicely(conn); + } + /* should PQclear PGresult whenever it is no longer needed to avoid + memory leaks */ + PQclear(res); + + /* fetch instances from the pg_database, the system catalog of databases*/ + res = PQexec(conn,"DECLARE mycursor BINARY CURSOR FOR select * from test1"); + if (PQresultStatus(res) != PGRES_COMMAND_OK) { + fprintf(stderr,"DECLARE CURSOR command failed\n"); + PQclear(res); + exit_nicely(conn); + } + PQclear(res); + + res = PQexec(conn,"FETCH ALL in mycursor"); + if (PQresultStatus(res) != PGRES_TUPLES_OK) { + fprintf(stderr,"FETCH ALL command didn't return tuples properly\n"); + PQclear(res); + exit_nicely(conn); + } + + i_fnum = PQfnumber(res,"i"); + d_fnum = PQfnumber(res,"d"); + p_fnum = PQfnumber(res,"p"); + + for (i=0;i<3;i++) { + printf("type[%d] = %d, size[%d] = %d\n", + i, PQftype(res,i), + i, PQfsize(res,i)); + } + for (i=0; i < PQntuples(res); i++) { + int *ival; + float *dval; + int plen; + POLYGON* pval; + /*/ + ival = (int*)PQgetvalue(res,i,i_fnum); + dval = (float*)PQgetvalue(res,i,d_fnum); + plen = PQgetlength(res,i,p_fnum); + + /* plen doesn't include the length field so need to increment by VARHDSZ*/ + pval = (POLYGON*) malloc(plen + VARHDRSZ); + pval->size = plen; + memmove((char*)&pval->npts, PQgetvalue(res,i,p_fnum), plen); + printf("tuple %d: got\n", i); + printf(" i = (%d bytes) %d,\n", + PQgetlength(res,i,i_fnum), *ival); + printf(" d = (%d bytes) %f,\n", + PQgetlength(res,i,d_fnum), *dval); + printf(" p = (%d bytes) %d points" + " boundbox = (hi=%f/%f" + ", lo = %f,%f)\n", + PQgetlength(res,i,d_fnum), + pval->npts, + pval->boundbox.xh, + pval->boundbox.yh, + pval->boundbox.xl, + pval->boundbox.yl); + } + + PQclear(res); + + /* close the cursor */ + res = PQexec(conn, "CLOSE mycursor"); + PQclear(res); + + /* end the transaction */ + res = PQexec(conn, "END"); + PQclear(res); + + /* close the connection to the database and cleanup */ + PQfinish(conn); + +} diff --git a/doc/src/sgml/odbc.sgml b/doc/src/sgml/odbc.sgml index 4ecc1d40f6..223eb415d3 100644 --- a/doc/src/sgml/odbc.sgml +++ b/doc/src/sgml/odbc.sgml @@ -41,34 +41,41 @@ This could be anything from a text file to an Oracle or Postgres RDBMS. -The backend access come from ODBC drivers, or vendor specifc drivers that -allow data access. psqlODBC is such a driver, along with others that are +The backend access come from ODBC drivers, +or vendor specifc drivers that +allow data access. psqlODBC is such a driver, + along with others that are available, such as the OpenLink ODBC drivers. -Once you write an ODBC application, you SHOULD be able to connect to ANY +Once you write an ODBC application, +you should be able to connect to any back end database, regardless of the vendor, as long as the database schema is the same. For example. you could have MS SQL Server and Postgres servers which have -exactly the same data. Using ODBC, your Windows app would make exactly the -same calls and the back end data source would look the same (to the windows +exactly the same data. Using ODBC, +your Windows app would make exactly the +same calls and the back end data source would look the same (to the Windows app). -Insight Distributors provides active and ongoing -support for the core psqlODBC distribution. They provide a -FAQ, ongoing development -on the code base, and actively participate on the +Insight Distributors +provides active and ongoing +support for the core psqlODBC distribution. +They provide a +FAQ, + ongoing development on the code base, and actively participate on the interfaces mailing list. <productname>Windows</productname> Applications -In the real world, differences in drivers and the level of ODBC support +In the real world, differences in drivers and the level of +ODBC support lessens the potential of ODBC: @@ -76,7 +83,8 @@ lessens the potential of ODBC: Access, Delphi, and Visual Basic all support ODBC directly. -Under C++, such as Visual C++, you can use the C++ ODBC API. +Under C++, such as Visual C++, +you can use the C++ ODBC API. In Visual C++, you can use the CRecordSet class, which wraps the @@ -88,24 +96,27 @@ Windows C++ development under Windows NT. If I write an app for Postgres can I write it using ODBC calls -to the Postgres server, or is that only when another database program +to the Postgres server, +or is that only when another database program like MS SQL Server or Access needs to access the data? -Again, the ODBC API set is the way to go. -You can find out more at -Microsoft's web site or in your Visual C++ docs (if that's what you are using.) +Again, the ODBC API set +is the way to go. +For Visual C++ you can find out more at +Microsoft's web site or in your docs. -Visual Basic and the other RAD tools have Recordset objects that use ODBC +Visual Basic and the other RAD tools have Recordset objects +that use ODBC directly to access data. Using the data-aware controls, you can quickly -link to the ODBC back end database (very quickly). +link to the ODBC back end database +(very quickly). Playing around with MS Access will help you sort this out. Try using -File->Get External Data +File->Get External Data. - You'll have to set up a DSN first. @@ -125,21 +136,103 @@ The Postgres datetime type will break MS Access. Unix Applications -ApplixWare has an ODBC database interface -supported on at least some platforms. ApplixWare v4.4.1 has been +ApplixWare has an +ODBC database interface +supported on at least some platforms. +ApplixWare v4.4.1 has been demonstrated under Linux with Postgres v6.4 using the psqlODBC driver contained in the Postgres distribution. +Building the Driver + + +The driver can be built in a standalone, client-only installation, or can be +built as a part of the main Postgres distribution. +The standalone installation is convenient if you have ODBC +client applications on multiple, heterogeneous platforms. The integrated +installation is convenient when the target client is the same as the +server, or when the client and server have similar runtime configurations. + + +Integrated Installation + + +For an integrated installation, specify the +command-line argument for src/configure: + + +./configure --with-odbc + + +Once configured, the ODBC driver will be built and installed +into the areas defined for the other components of the +Postgres system. The installation-wide +ODBC configuration file will be placed into +the top directory of the Postgres target tree (POSTGRESDIR). +This can be overridden from the make command-line +as + +% make ODBCINST=filename + + + +Standalone Installation + + +A standalone installation is not integrated with or built on the normal +Postgres distribution. It should be best suited +for building the ODBC driver for multiple, heterogeneous +clients who do not have a locally-installed Postgres +source tree. + + +The standalone installation distribution can be built from the +Postgres distribution or may be obtained +from Insight Distributors, +the current maintainers of the non-Unix sources. + + +To create a tar file for a complete standalone installation, first +configure the main Postgres distribution. +Then, create the tar file: + + +% cd interfaces/odbc +% make standalone + + + +Copy the output tar file to your target system, unpack it into a clean +directory, and then: + + +% ./configure --with-odbcinst=instfile +% make POSTGRESDIR=targettree ODBCINST=instfile + + + + +The ODBCINST can be specified on either or both command lines. + + + +If you would like to install components into different trees, then you +can specify various destinations explicitly: + + +% make BINDIR=bindir LIBDIR=libdir HEADERDIR=headerdir ODBCINST=instfile + + + Configuration Files -The ~/.odbc.ini contains user-specified access information -for the psqlODBC -driver. The file uses conventions typical for Windows -Registry files, but despite this -restriction can be made to work. +~/.odbc.ini contains user-specified access information +for the psqlODBC driver. +The file uses conventions typical for Windows +Registry files, but despite this restriction can be made to work. Here is an example .odbc.ini file, diff --git a/doc/src/sgml/ports.sgml b/doc/src/sgml/ports.sgml index 35d478fce3..08c7e24474 100644 --- a/doc/src/sgml/ports.sgml +++ b/doc/src/sgml/ports.sgml @@ -115,7 +115,7 @@ linux 2.0.x x86 v6.4 - 1998-09-14 + 1998-10-09 (Thomas Lockhart, Tatsuo Ishii) @@ -165,9 +165,9 @@ SVR4 MIPS - v6.3 - 1998-03-01 - similar to v6.2.1; "mostly working" (Frank Ridderbusch) + v6.4 + 1998-10-08 + no 64-bit int support (Frank Ridderbusch) SVR4 4.4 @@ -179,21 +179,27 @@ Unixware x86 - v6.3 - 1998-03-01 + v6.4 + 1998-10-04 aka UNIVEL (Billy G. Allie) - NextStep + Windows NT x86 - v6.x - 1998-03-01 - client-only support; v1.0.9 worked with patches (David Wetzel) + v6.4 + 1998-10-08 + Mostly working with the Cygwin library. No DLLs yet. Horak Daniel + + +For Windows NT, look for patches on the +Postgres web site. + + Unsupported Platforms @@ -238,18 +244,18 @@ Others listed here do not provide sufficient library support for an attempt. Amiga, HP300, Mac; not yet working (Henry Hotz) - Ultrix - MIPS,VAX? + NextStep + x86 v6.x 1998-03-01 - no recent reports; obsolete? + client-only support; v1.0.9 worked with patches (David Wetzel) - Windows NT - all - v6.3 + Ultrix + MIPS,VAX? + v6.x 1998-03-01 - not library compatible; client side maybe; use ODBC/JDBC + no recent reports; obsolete? Windows diff --git a/doc/src/sgml/programmer.sgml b/doc/src/sgml/programmer.sgml index 2a5b1c782a..301fbb7882 100644 --- a/doc/src/sgml/programmer.sgml +++ b/doc/src/sgml/programmer.sgml @@ -55,6 +55,7 @@ $log$ + @@ -135,8 +136,8 @@ Your name here... 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 - of this original Berkeley code. + PostgreSQL is a public-domain, + open source descendant of this original Berkeley code. @@ -151,16 +152,17 @@ It provides SQL92/SQL3 language support, &xindex; &gist; &dfunc; -&trigger; -&spi; &func-ref; +&trigger; +&spi; &lobj; -&ecpg; &libpq; +&libpqpp; &libpgtcl; +&ecpg; &odbc; &jdbc; -- 2.11.0