Skip to content

P
Postgres FD Implementation
Commit cc4f5769 authored by Peter Eisentraut's avatar Peter Eisentraut
Browse files
Options

Improve ECPG documentation.

parent cf8da4e9
Hide whitespace changes
Inline Side-by-side
Showing with 1152 additions and 1298 deletions
doc/src/sgml/ecpg.sgml
View file @ cc4f5769
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.37 2002/09/21 18:32:52 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/ecpg.sgml,v 1.38 2002/10/21 18:04:05 petere Exp $
--> -->
<chapter id="ecpg"> <chapter id="ecpg">
<docinfo> <title><application>ECPG</application> - Embedded <acronym>SQL</acronym> in C</title>
<authorgroup>
<author> <indexterm zone="ecpg"><primary>embedded SQL</primary><secondary>in C</secondary></indexterm>
<firstname>Linus</firstname>
<surname>Tolke</surname> <para>
</author> This chapter describes the embedded <acronym>SQL</acronym> package
<author> for <productname>PostgreSQL</productname>. It works with
<firstname>Michael</firstname> <acronym>C</acronym> and <acronym>C++</acronym>. It was written by
<surname>Meskes</surname> Linus Tolke (<email>linus@epact.se</email>) and Michael Meskes
</author> (<email>meskes@postgresql.org</email>).
</authorgroup> </para>
<copyright>
<year>1996-1997</year> <para>
<holder>Linus Tolke</holder> Admittedly, this documentation is quite incomplete. But since this
</copyright> interface is standardized, additional information can be found in
<copyright> many resources about SQL.
<year>1998</year> </para>
<holder>Michael Meskes</holder>
</copyright> <sect1 id="ecpg-concept">
<date>Transcribed 1998-02-12</date> <title>The Concept</title>
</docinfo>
<title><application>ecpg</application> - Embedded <acronym>SQL</acronym>
in <acronym>C</acronym></title>
<indexterm zone="ecpg"><primary>embedded SQL</primary><secondary>in C</secondary></indexterm>
<para> <para>
This describes the embedded <acronym>SQL</acronym> package for An embedded SQL program consists of code written in an ordinary
<productname>PostgreSQL</productname>. It works with programming language, in this case C, mixed with SQL commands in
<acronym>C</acronym> and <acronym>C++</acronym>. It was written by specially marked sections. To build the program, the source code
Linus Tolke (<email>linus@epact.se</email>) and Michael Meskes is first passed to the embedded SQL preprocessor, which converts it
(<email>meskes@debian.org</email>). The package is installed with the to an ordinary C program, and afterwards it can be processed by a C
<productname>PostgreSQL</> distribution, and carries a similar license. compilation tool chain.
</para> </para>
<sect1 id="ecpg-why"> <para>
<title>Why Embedded <acronym>SQL</acronym>?</title> Embedded <acronym>SQL</acronym> has advantages over other methods
for handling <acronym>SQL</acronym> commands from C code. First, it
takes care of the tedious passing of information to and from
variables in your <acronym>C</acronym> program. Secondly, embedded
SQL in C is defined in the SQL standard and supported by many other
SQL databases. The PostgreSQL implementation is designed to match
this standard as much as possible, and it is usually possible to
port embedded <acronym>SQL</acronym> programs written for other
<acronym>RDBMS</acronym> to <productname>PostgreSQL</productname>
with relative ease.
</para>
<para> <para>
Embedded <acronym>SQL</acronym> has advantages over other methods As indicated, programs written for the embedded SQL interface are
for handling <acronym>SQL</acronym> queries. It takes care of normal C programs with special code inserted to perform
the tedious passing of information to and from variables in your database-related actions. This special code always has the form
<acronym>C</acronym> or <acronym>C++</acronym> program. Many <programlisting>
<acronym>RDBMS</acronym> packages support this embedded language. EXEC SQL ...;
</para> </programlisting>
These statements syntactically take the place of a C statement.
Depending on the particular statement, they may appear in the
global context or within a function. Embedded SQL statements
follow the case-sensitivity rules of normal SQL code, and not those
of C.
</para>
<para> <para>
There is an ANSI standard describing how the embedded language The following sections explain all the embedded SQL statements.
should work. <application>ecpg</application> was designed to match </para>
this standard as much as possible. It is possible to port embedded </sect1>
<acronym>SQL</acronym> programs written for other
<acronym>RDBMS</acronym> to <productname>PostgreSQL</productname>.
</para>
</sect1>
<sect1 id="ecpg-concept"> <sect1 id="ecpg-connect">
<title>The Concept</title> <title>Connecting to the Database Server</title>
<para> <para>
You write your program in <acronym>C/C++</acronym> with special One connects to a database using the following statement:
<acronym>SQL</acronym> constructs. When declaring variables to be <programlisting>
used in <acronym>SQL</acronym> statements, you need to put them in a EXEC SQL CONNECT TO <replaceable>target</replaceable> <optional>AS <replaceable>connection-name</replaceable></optional> <optional>USER <replaceable>user-name</replaceable></optional>;
special <command>declare</> section. You use a special syntax for the </programlisting>
<acronym>SQL</acronym> queries. The <replaceable>target</replaceable> can be specified in the
</para> following ways:
<itemizedlist>
<listitem>
<simpara>
<literal><replaceable>dbname</><optional>@<replaceable>hostname</></optional><optional>:<replaceable>port</></optional></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>tcp:postgresql://<replaceable>hostname</><optional>:<replaceable>port</></optional><optional>/<replaceable>dbname</></optional><optional>?<replaceable>options</></optional></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>unix:postgresql://<replaceable>hostname</><optional>:<replaceable>port</></optional><optional>/<replaceable>dbname</></optional><optional>?<replaceable>options</></optional></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>character variable</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>character string</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>DEFAULT</literal>
</simpara>
</listitem>
</itemizedlist>
</para>
<para> <para>
Before compiling you run the file through the embedded There are also different ways to specify the user name:
<acronym>SQL</acronym> <acronym>C</acronym> preprocessor and it
converts the <acronym>SQL</acronym> statements you used to function <itemizedlist>
calls with the variables used as arguments. Both query input and <listitem>
result output variables are passed. <simpara>
</para> <literal><replaceable>userid</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable>/<replaceable>password</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable> IDENTIFIED BY <replaceable>password</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable> USING <replaceable>password</replaceable></literal>
</simpara>
</listitem>
</itemizedlist>
The <replaceable>userid</replaceable> and
<replaceable>password</replaceable> may be a constant text, a
character variable, or a character string.
</para>
<para> <para>
After compiling, you must link with a special library that contains The <replaceable>connection-name</replaceable> is used to handle
needed functions. These functions fetch information from the multiple connections in one program. It can be omitted if a
arguments, perform the <acronym>SQL</acronym> query using the program uses only one connection.
<filename>libpq</filename> interface, and put the result in the </para>
arguments specified for output. </sect1>
</para>
</sect1>
<sect1 id="ecpg-use"> <sect1 id="ecpg-disconnect">
<title>How To Use <application>ecpg</application></title> <title>Closing a Connection</title>
<para> <para>
This section describes how to use <application>ecpg</application>. To close a connection, use the following statement:
</para> <programlisting>
EXEC SQL DISCONNECT [<replaceable>connection</replaceable>];
</programlisting>
The <replaceable>connection</replaceable> can be specified
in the following ways:
<itemizedlist>
<listitem>
<simpara>
<literal><replaceable>connection-name</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>DEFAULT</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>CURRENT</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>ALL</literal>
</simpara>
</listitem>
</itemizedlist>
</para>
</sect1>
<sect2> <sect1 id="ecpg-commands">
<title>Preprocessor</title> <title>Running SQL Commands</title>
<para> <para>
The preprocessor is called <application>ecpg</application>. After Any SQL command can be run from within an embedded SQL application.
installation it resides in the <productname>PostgreSQL</productname> Below are some examples of how to do that.
<filename>bin/</filename> directory. </para>
</para>
</sect2>
<sect2>
<title>Library</title>
<para> <para>
The <application>ecpg</application> library is called Creating a table:
<filename>libecpg.a</filename> or <filename>libecpg.so</filename>. <programlisting>
Additionally, the library uses the <filename>libpq</filename> EXEC SQL CREATE TABLE foo (number integer, ascii char(16));
library for communication to the EXEC SQL CREATE UNIQUE INDEX num1 ON foo(number);
<productname>PostgreSQL</productname> server. You will have to link EXEC SQL COMMIT;
your program using <parameter>-lecpg -lpq</parameter>. </programlisting>
</para> </para>
<para> <para>
The library has some methods that are <quote>hidden</quote> but may prove Inserting rows:
useful. <programlisting>
EXEC SQL INSERT INTO foo (number, ascii) VALUES (9999, 'doodad');
EXEC SQL COMMIT;
</programlisting>
</para>
<itemizedlist> <para>
<listitem> Deleting rows:
<para> <programlisting>
<function>ECPGdebug(int <replaceable>on</replaceable>, FILE EXEC SQL DELETE FROM foo WHERE number = 9999;
*<replaceable>stream</replaceable>)</function> turns on debug EXEC SQL COMMIT;
logging if called with the first argument non-zero. Debug </programlisting>
logging is done on <replaceable>stream</replaceable>. Most </para>
<acronym>SQL</acronym> statement log their arguments and results.
</para>
<para> <para>
The most important function , <function>ECPGdo</function>, logs Singleton Select:
all <acronym>SQL</acronym> statements with both the expanded <programlisting>
string, i.e. the string with all the input variables inserted, EXEC SQL SELECT foo INTO :FooBar FROM table1 WHERE ascii = 'doodad';
and the result from the <productname>PostgreSQL</productname> </programlisting>
server. This can be very useful when searching for errors in </para>
your <acronym>SQL</acronym> statements.
</para>
</listitem>
<listitem> <para>
<para> Select using Cursors:
<function>ECPGstatus()</function> <programlisting>
This method returns TRUE if we are connected to a database and FALSE if not. EXEC SQL DECLARE foo_bar CURSOR FOR
</para> SELECT number, ascii FROM foo
</listitem> ORDER BY ascii;
</itemizedlist> EXEC SQL FETCH foo_bar INTO :FooBar, DooDad;
</para> ...
</sect2> EXEC SQL CLOSE foo_bar;
EXEC SQL COMMIT;
</programlisting>
</para>
<para>
Updates:
<programlisting>
EXEC SQL UPDATE foo
SET ascii = 'foobar'
WHERE number = 9999;
EXEC SQL COMMIT;
</programlisting>
</para>
<sect2> <para>
<title>Error handling</title> The tokens of the form
<literal>:<replaceable>something</replaceable></literal> are
<firstterm>host variables</firstterm>, that is, they refer to
variables in the C program. They are explained in the next
section.
</para>
<para> <para>
To detect errors from the <productname>PostgreSQL</productname> In the default mode, statements are committed only when
server, include a line like: <command>EXEC SQL COMMIT</command> is issued. The embedded SQL
interface also supports autocommit of transactions (as known from
other interfaces) via the <option>-t</option> command-line option
to <command>ecpg</command> (see below) or via the <literal>EXEC SQL
SET AUTOCOMMIT TO ON</literal> statement. In autocommit mode, each
query is automatically committed unless it is inside an explicit
transaction block. This mode can be explicitly turned off using
<literal>EXEC SQL SET AUTOCOMMIT TO OFF</literal>.
</para>
</sect1>
<sect1 id="ecpg-variables">
<title>Passing Data</title>
<para>
To pass data from the program to the database, for example as
parameters in a query, or to pass data from the database back to
the program, the C variables that are intended to contain this data
need to be declared in a specially marked section, so the embedded
SQL preprocessor is made aware of them.
</para>
<para>
This section starts with
<programlisting> <programlisting>
exec sql include sqlca; EXEC SQL BEGIN DECLARE SECTION;
</programlisting> </programlisting>
in the include section of your file. This will define a <type>struct</> and and ends with
a variable with the name <varname>sqlca</varname> as follows:
<programlisting> <programlisting>
struct sqlca EXEC SQL END DECLARE SECTION;
{
char sqlcaid[8];
long sqlabc;
long sqlcode;
struct
{
int sqlerrml;
char sqlerrmc[70];
} sqlerrm;
char sqlerrp[8];
long sqlerrd[6];
/* 0: empty */
/* 1: OID of processed tuple if applicable */
/* 2: number of rows processed in an INSERT, UPDATE */
/* or DELETE statement */
/* 3: empty */
/* 4: empty */
/* 5: empty */
char sqlwarn[8];
/* 0: set to 'W' if at least one other is 'W' */
/* 1: if 'W' at least one character string */
/* value was truncated when it was */
/* stored into a host variable. */
/* 2: empty */
/* 3: empty */
/* 4: empty */
/* 5: empty */
/* 6: empty */
/* 7: empty */
char sqlext[8];
} sqlca;
</programlisting> </programlisting>
</para> Between those lines, there must be normal C variable declarations, such as
<programlisting>
int x;
char foo[16], bar[16];
</programlisting>
</para>
<para> <para>
If an no error occurred in the last <acronym>SQL</acronym> statement. The declarations are also echoed to the output file as a normal C
<parameter>sqlca.sqlcode</parameter> will be 0 (<symbol>ECPG_NO_ERROR</>). If variables, so there's no need to declare them again. Variables
<parameter>sqlca.sqlcode</parameter> is less that zero, this is a that are not intended to be used with SQL commands can be declared
serious error, like the database definition does not match the normally outside these special sections.
query. If it is greater than zero, it is a normal error like the </para>
table did not contain the requested row.
</para>
<para> <para>
<parameter>sqlca.sqlerrm.sqlerrmc</parameter> will contain a string The definition of a structure or union also must be listed inside a
that describes the error. The string ends with the line number in <literal>DECLARE</> section. Otherwise the preprocessor cannot
the source file. handle these types since it does not know the definition.
</para> </para>
<para> <para>
These are the errors that can occur: The special types <type>VARCHAR</type> and <type>VARCHAR2</type>
are converted into a named <type>struct</> for every variable. A
declaration like:
<programlisting>
VARCHAR var[180];
</programlisting>
is converted into:
<programlisting>
struct varchar_var { int len; char arr[180]; } var;
</programlisting>
This structure is suitable for interfacing with SQL datums of type
<type>VARCHAR</type>.
</para>
<variablelist> <para>
<varlistentry> To use a properly declared C variable in an SQL statement, write
<term><computeroutput>-12, Out of memory in line %d.</computeroutput></term> <literal>:<replaceable>varname</></literal> where an expression is
<listitem> expected. See the previous section for some examples.
<para> </para>
Should not normally occur. This indicates your virtual memory is </sect1>
exhausted.
</para>
</listitem>
</varlistentry>
<varlistentry> <sect1 id="ecpg-errors">
<term><computeroutput>-200 (ECPG_UNSUPPORTED): Unsupported type %s on line %d.</computeroutput></term> <title>Error Handling</title>
<listitem>
<para>
Should not normally occur. This indicates the preprocessor has
generated something that the library does not know about.
Perhaps you are running incompatible versions of the
preprocessor and the library.
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-201 (ECPG_TOO_MANY_ARGUMENTS): Too many arguments line %d.</computeroutput></term> The embedded SQL interface provides a simplistic and a complex way
<listitem> to handle exceptional conditions in a program. The first method
<para> causes a message to printed automatically when a certain condition
This means that <productname>PostgreSQL</productname> has occurs. For example:
returned more arguments than we have matching variables. <programlisting>
Perhaps you have forgotten a couple of the host variables in EXEC SQL WHENEVER sqlerror sqlprint;
the <command>INTO :var1,:var2</command>-list. </programlisting>
</para> or
</listitem> <programlisting>
</varlistentry> EXEC SQL WHENEVER not found sqlprint;
</programlisting>
This error handling remains enabled throughout the entire program.
</para>
<varlistentry> <note>
<term><computeroutput>-202 (ECPG_TOO_FEW_ARGUMENTS): Too few arguments line %d.</computeroutput></term> <para>
<listitem> This is <emphasis>not</emphasis> an exhaustive example of usage
<para> for the <command>EXEC SQL WHENEVER</command> statement. Further
This means that <productname>PostgreSQL</productname> has examples of usage may be found in SQL manuals (e.g.,
returned fewer arguments than we have host variables. Perhaps <citetitle>The LAN TIMES Guide to SQL</> by Groff and Weinberg).
you have too many host variables in the <command>INTO </para>
:var1,:var2</command>-list. </note>
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-203 (ECPG_TOO_MANY_MATCHES): Too many matches line %d.</computeroutput></term> For a more powerful error handling, the embedded SQL interface
<listitem> provides a <type>struct</> and a variable with the name
<para> <varname>sqlca</varname> as follows:
This means the query has returned several rows but the <programlisting>
variables specified are not arrays. The struct sqlca
<command>SELECT</command> command was not unique. {
</para> char sqlcaid[8];
</listitem> long sqlabc;
</varlistentry> long sqlcode;
struct
{
int sqlerrml;
char sqlerrmc[70];
} sqlerrm;
char sqlerrp[8];
long sqlerrd[6];
/* 0: empty */
/* 1: OID of processed tuple if applicable */
/* 2: number of rows processed in an INSERT, UPDATE */
/* or DELETE statement */
/* 3: empty */
/* 4: empty */
/* 5: empty */
char sqlwarn[8];
/* 0: set to 'W' if at least one other is 'W' */
/* 1: if 'W' at least one character string */
/* value was truncated when it was */
/* stored into a host variable. */
/* 2: empty */
/* 3: empty */
/* 4: empty */
/* 5: empty */
/* 6: empty */
/* 7: empty */
char sqlext[8];
} sqlca;
</programlisting>
(Many of the empty fields may be used in a future release.)
</para>
<varlistentry> <para>
<term><computeroutput>-204 (ECPG_INT_FORMAT): Not correctly formatted int type: %s line %d.</computeroutput></term> If no error occurred in the last <acronym>SQL</acronym> statement,
<listitem> <literal>sqlca.sqlcode</literal> will be 0
<para> (<symbol>ECPG_NO_ERROR</>). If <literal>sqlca.sqlcode</literal> is
This means the host variable is of type <type>int</type> and less that zero, this is a serious error, like the database
the field in the <productname>PostgreSQL</productname> database definition does not match the query. If it is greater than zero, it
is of another type and contains a value that cannot be is a normal error like the table did not contain the requested row.
interpreted as an <type>int</type>. The library uses </para>
<function>strtol()</function> for this conversion.
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-205 (ECPG_UINT_FORMAT): Not correctly formatted unsigned type: %s line %d.</computeroutput></term> <literal>sqlca.sqlerrm.sqlerrmc</literal> will contain a string
<listitem> that describes the error. The string ends with the line number in
<para> the source file.
This means the host variable is of type <type>unsigned </para>
int</type> and the field in the
<productname>PostgreSQL</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>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-206 (ECPG_FLOAT_FORMAT): Not correctly formatted floating-point type: %s line %d.</computeroutput></term> These are the errors that can occur:
<listitem>
<para> <variablelist>
This means the host variable is of type <type>float</type> and <varlistentry>
the field in the <productname>PostgreSQL</productname> database <term><computeroutput>-12, Out of memory in line %d.</computeroutput></term>
is of another type and contains a value that cannot be <listitem>
interpreted as a <type>float</type>. The library uses <para>
<function>strtod()</function> for this conversion. Should not normally occur. This indicates your virtual memory
</para> is exhausted.
</listitem> </para>
</varlistentry> </listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-200 (ECPG_UNSUPPORTED): Unsupported type %s on line %d.</computeroutput></term>
<listitem>
<para>
Should not normally occur. This indicates the preprocessor has
generated something that the library does not know about.
Perhaps you are running incompatible versions of the
preprocessor and the library.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-201 (ECPG_TOO_MANY_ARGUMENTS): Too many arguments line %d.</computeroutput></term>
<listitem>
<para>
This means that the server has returned more arguments than we
have matching variables. Perhaps you have forgotten a couple
of the host variables in the <command>INTO
:var1,:var2</command> list.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-202 (ECPG_TOO_FEW_ARGUMENTS): Too few arguments line %d.</computeroutput></term>
<listitem>
<para>
This means that the server has returned fewer arguments than we
have host variables. Perhaps you have too many host variables
in the <command>INTO :var1,:var2</command> list. </para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-203 (ECPG_TOO_MANY_MATCHES): Too many matches line %d.</computeroutput></term>
<listitem>
<para>
This means the query has returned several rows but the
variables specified are not arrays. The
<command>SELECT</command> command was not unique.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-204 (ECPG_INT_FORMAT): Not correctly formatted int type: %s line %d.</computeroutput></term>
<listitem>
<para>
This means the host variable is of type <type>int</type> and
the field in the <productname>PostgreSQL</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>
</varlistentry>
<varlistentry>
<term><computeroutput>-205 (ECPG_UINT_FORMAT): Not correctly formatted unsigned type: %s line %d.</computeroutput></term>
<listitem>
<para>
This means the host variable is of type <type>unsigned
int</type> and the field in the
<productname>PostgreSQL</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>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-206 (ECPG_FLOAT_FORMAT): Not correctly formatted floating-point type: %s line %d.</computeroutput></term>
<listitem>
<para>
This means the host variable is of type <type>float</type> and
the field in the <productname>PostgreSQL</productname> database
is of another type and contains a value that cannot be
interpreted as a <type>float</type>. The library uses
<function>strtod()</function> for this conversion.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-207 (ECPG_CONVERT_BOOL): Unable to convert %s to bool on line %d.</computeroutput></term>
<listitem>
<para>
This means the host variable is of type <type>bool</type> and
the field in the <productname>PostgreSQL</productname> database
is neither <literal>'t'</> nor <literal>'f'</>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-208 (ECPG_EMPTY): Empty query line %d.</computeroutput></term>
<listitem>
<para>
The query was empty. (This cannot normally happen in an
embedded SQL program, so it may point to an internal error.)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-209 (ECPG_MISSING_INDICATOR): NULL value without indicator in line %d.</computeroutput></term>
<listitem>
<para>
A null value was returned and no null indicator variable was
supplied.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-210 (ECPG_NO_ARRAY): Variable is not an array in line %d.</computeroutput></term>
<listitem>
<para>
An ordinary variable was used in a place that requires an
array.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-211 (ECPG_DATA_NOT_ARRAY): Data read from backend is not an array in line %d.</computeroutput></term>
<listitem>
<para>
The database returned an ordinary variable in a place that
requires array value.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-220 (ECPG_NO_CONN): No such connection %s in line %d.</computeroutput></term>
<listitem>
<para>
The program tried to access a connection that does not exist.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-221 (ECPG_NOT_CONN): Not connected in line %d.</computeroutput></term>
<listitem>
<para>
The program tried to access a connection that does exist but is
not open.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-230 (ECPG_INVALID_STMT): Invalid statement name %s in line %d.</computeroutput></term>
<listitem>
<para>
The statement you are trying to use has not been prepared.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-240 (ECPG_UNKNOWN_DESCRIPTOR): Descriptor %s not found in line %d.</computeroutput></term>
<listitem>
<para>
The descriptor specified was not found. The statement you are
trying to use has not been prepared.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-241 (ECPG_INVALID_DESCRIPTOR_INDEX): Descriptor index out of range in line %d.</computeroutput></term>
<listitem>
<para>
The descriptor index specified was out of range.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-242 (ECPG_UNKNOWN_DESCRIPTOR_ITEM): Descriptor %s not found in line %d.</computeroutput></term>
<listitem>
<para>
The descriptor specified was not found. The statement you are trying to use has not been prepared.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-243 (ECPG_VAR_NOT_NUMERIC): Variable is not a numeric type in line %d.</computeroutput></term>
<listitem>
<para>
The database returned a numeric value and the variable was not
numeric.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-244 (ECPG_VAR_NOT_CHAR): Variable is not a character type in line %d.</computeroutput></term>
<listitem>
<para>
The database returned a non-numeric value and the variable was
numeric.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-400 (ECPG_PGSQL): Postgres error: %s line %d.</computeroutput></term>
<listitem>
<para>
Some <productname>PostgreSQL</productname> error. The message
contains the error message from the
<productname>PostgreSQL</productname> backend.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-401 (ECPG_TRANS): Error in transaction processing line %d.</computeroutput></term>
<listitem>
<para>
<productname>PostgreSQL</productname> signaled that we cannot
start, commit, or rollback the transaction.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-402 (ECPG_CONNECT): Could not connect to database %s in line %d.</computeroutput></term>
<listitem>
<para>
The connect to the database did not work.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>100 (ECPG_NOT_FOUND): Data not found line %d.</computeroutput></term>
<listitem>
<para>
This is a <quote>normal</quote> error that tells you that what
you are querying cannot be found or you are at the end of the
cursor.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect1>
<varlistentry> <sect1 id="ecpg-include">
<term><computeroutput>-207 (ECPG_CONVERT_BOOL): Unable to convert %s to bool on line %d.</computeroutput></term> <title>Including Files</title>
<listitem>
<para>
This means the host variable is of type <type>bool</type> and
the field in the <productname>PostgreSQL</productname> database
is neither <literal>'t'</> nor <literal>'f'</>.
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-208 (ECPG_EMPTY): Empty query line %d.</computeroutput></term> To include an external file into your embedded SQL program, use:
<listitem> <programlisting>
<para> EXEC SQL INCLUDE <replaceable>filename</replaceable>;
<productname>PostgreSQL</productname> returned <symbol>PGRES_EMPTY_QUERY</symbol>, probably </programlisting>
because the query indeed was empty. The embedded SQL preprocessor will look for a file named
</para> <literal><replaceable>filename</replaceable>.h</literal>,
</listitem> preprocess it, and include it in the resulting C output. Thus,
</varlistentry> embedded SQL statements in the included file are handled correctly.
</para>
<varlistentry> <para>
<term><computeroutput>-209 (ECPG_MISSING_INDICATOR): NULL value without indicator in line %d.</computeroutput></term> Note that this is <emphasis>not</emphasis> the same as
<listitem> <programlisting>
<para> #include &lt;<replaceable>filename</replaceable>.h&gt;
<productname>PostgreSQL</productname> returned <symbol>ECPG_MISSING_INDICATOR</symbol> </programlisting>
because a NULL was returned and no NULL indicator variable was supplied. because the file would not be subject to SQL command preprocessing.
</para> Naturally, you can continue to use the C
</listitem> <literal>#include</literal> directive to include other header
</varlistentry> files.
</para>
<varlistentry> <note>
<term><computeroutput>-210 (ECPG_NO_ARRAY): Variable is not an array in line %d.</computeroutput></term> <para>
<listitem> The include file name is case-sensitive, even though the rest of
<para> the <literal>EXEC SQL INCLUDE</literal> command follows the normal
<productname>PostgreSQL</productname> returned <symbol>ECPG_NO_ARRAY</symbol> SQL case-sensitivity rules.
because an ordinary variable was used in a place that requires </para>
an array. </note>
</para> </sect1>
</listitem>
</varlistentry>
<varlistentry> <sect1 id="ecpg-process">
<term><computeroutput>-211 (ECPG_DATA_NOT_ARRAY): Data read from backend is not an array in line %d.</computeroutput></term> <title>Processing Embedded SQL Programs</title>
<listitem>
<para>
<productname>PostgreSQL</productname> returned <symbol>ECPG_DATA_NOT_ARRAY</symbol>
because the database returned an ordinary variable in a place
that requires array value.
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-220 (ECPG_NO_CONN): No such connection %s in line %d.</computeroutput></term> Now that you have an idea how to form embedded SQL C programs, you
<listitem> probably want to know how to compile them. Before compiling you
<para> run the file through the embedded <acronym>SQL</acronym>
The program tried to access a connection that does not exist. <acronym>C</acronym> preprocessor, which converts the
</para> <acronym>SQL</acronym> statements you used to special function
</listitem> calls. After compiling, you must link with a special library that
</varlistentry> contains the needed functions. These functions fetch information
from the arguments, perform the <acronym>SQL</acronym> query using
the <application>libpq</application> interface, and put the result
in the arguments specified for output.
</para>
<varlistentry> <para>
<term><computeroutput>-221 (ECPG_NOT_CONN): Not connected in line %d.</computeroutput></term> The preprocessor program is called <filename>ecpg</filename> and is
<listitem> included in a normal PostgreSQL installation. Embedded SQL
<para> programs are typically named with an extension
The program tried to access a connection that does exist but is <filename>.pgc</filename>. If you have a program file called
not open. <filename>prog1.pgc</filename>, you can preprocess it by simply
</para> calling
</listitem> <programlisting>
</varlistentry> ecpg prog1.pgc
</programlisting>
This will create a file called <filename>prog1.c</filename>. If
your input files do not follow the suggested naming pattern, you
can specify the output file explicitly using the
<option>-o</option> option.
</para>
<varlistentry> <para>
<term><computeroutput>-230 (ECPG_INVALID_STMT): Invalid statement name %s in line %d.</computeroutput></term> The preprocessed file can be compiled normally, for example
<listitem> <programlisting>
<para> cc -c prog1.c
The statement you are trying to use has not been prepared. </programlisting>
</para> The generated C source files include headers files from the
</listitem> PostgreSQL installation, so if you installed PostgreSQL in a
</varlistentry> location that is not searched by default, you have to add an option
such as <literal>-I/usr/local/pgsql/include</literal> to the
compilation command line.
</para>
<varlistentry> <para>
<term><computeroutput>-240 (ECPG_UNKNOWN_DESCRIPTOR): Descriptor %s not found in line %d.</computeroutput></term> To link an embedded SQL program, you need to include the
<listitem> <filename>libecpg</filename> library, like so:
<para> <programlisting>
The descriptor specified was not found. The statement you are trying to use has not been prepared. cc -o myprog prog1.o prog2.o ... -lecpg
</para> </programlisting>
</listitem> Again, you might have to add an option like
</varlistentry> <literal>-L/usr/local/pgsql/lib</literal> to that command line.
</para>
<varlistentry> <para>
<term><computeroutput>-241 (ECPG_INVALID_DESCRIPTOR_INDEX): Descriptor index out of range in line %d.</computeroutput></term> If you manage the build process of a larger project using
<listitem> <application>make</application>, it may be convenient to include
<para> the following implicit rule to your makefiles:
The descriptor index specified was out of range. <programlisting>
</para> ECPG = ecpg
</listitem>
</varlistentry>
<varlistentry> %.c: %.pgc
<term><computeroutput>-242 (ECPG_UNKNOWN_DESCRIPTOR_ITEM): Descriptor %s not found in line %d.</computeroutput></term> $(ECPG) $<
<listitem> </programlisting>
<para> </para>
The descriptor specified was not found. The statement you are trying to use has not been prepared.
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-243 (ECPG_VAR_NOT_NUMERIC): Variable is not a numeric type in line %d.</computeroutput></term> The complete syntax of the <command>ecpg</command> command is
<listitem> detailed in &cite-reference;.
<para> </para>
The database returned a numeric value and the variable was not </sect1>
numeric.
</para>
</listitem>
</varlistentry>
<varlistentry> <sect1 id="ecpg-library">
<term><computeroutput>-244 (ECPG_VAR_NOT_CHAR): Variable is not a character type in line %d.</computeroutput></term> <title>Library Functions</title>
<listitem>
<para>
The database returned a non-numeric value and the variable was
numeric.
</para>
</listitem>
</varlistentry>
<varlistentry> <para>
<term><computeroutput>-400 (ECPG_PGSQL): Postgres error: %s line %d.</computeroutput></term> The <filename>libecpg</filename> library primarily contains
<listitem> <quote>hidden</quote> functions that are used to implement the
<para> functionality expressed by the embedded SQL commands. But there
Some <productname>PostgreSQL</productname> error. are some functions that can usefully be called directly. Note that
The message contains the error message from the this makes your code unportable.
<productname>PostgreSQL</productname> backend. </para>
</para>
</listitem>
</varlistentry>
<varlistentry> <itemizedlist>
<term><computeroutput>-401 (ECPG_TRANS): Error in transaction processing line %d.</computeroutput></term> <listitem>
<listitem> <para>
<para> <function>ECPGdebug(int <replaceable>on</replaceable>, FILE
<productname>PostgreSQL</productname> signaled that we cannot start, *<replaceable>stream</replaceable>)</function> turns on debug
commit or rollback the transaction. logging if called with the first argument non-zero. Debug logging
</para> is done on <replaceable>stream</replaceable>. Most
</listitem> <acronym>SQL</acronym> statement log their arguments and results.
</varlistentry> </para>
<varlistentry> <para>
<term><computeroutput>-402 (ECPG_CONNECT): Could not connect to database %s in line %d.</computeroutput></term> The most important function, <function>ECPGdo</function>, logs
<listitem> all <acronym>SQL</acronym> statements with both the expanded
<para> string, i.e. the string with all the input variables inserted,
The connect to the database did not work. and the result from the <productname>PostgreSQL</productname>
</para> server. This can be very useful when searching for errors in your
</listitem> <acronym>SQL</acronym> statements.
</varlistentry> </para>
</listitem>
<varlistentry> <listitem>
<term><computeroutput>100 (ECPG_NOT_FOUND): Data not found line %d.</computeroutput></term> <para>
<listitem> <function>ECPGstatus()</function> This method returns true if we
<para> are connected to a database and false if not.
This is a <quote>normal</quote> error that tells you that what you are querying cannot
be found or you are at the end of the cursor.
</para>
</listitem>
</varlistentry>
</variablelist>
</para> </para>
</sect2> </listitem>
</sect1> </itemizedlist>
</sect1>
<sect1 id="ecpg-limitations"> <sect1 id="ecpg-porting">
<title>Limitations</title> <title>Porting From Other <acronym>RDBMS</acronym> Packages</title>
<para> <para>
What will never be included and why it cannot be done: The design of <application>ecpg</application> follows the SQL
standard. Porting from a standard RDBMS should not be a problem.
Unfortunately there is no such thing as a standard RDBMS. Therefore
<application>ecpg</application> tries to understand syntax
extensions as long as they do not create conflicts with the
standard.
</para>
<variablelist> <para>
<varlistentry> The following list shows all the known incompatibilities. If you
<term>Oracle's single tasking</term> find one not listed please notify the developers. Note, however,
<listitem> that we list only incompatibilities from a preprocessor of another
<para> RDBMS to <application>ecpg</application> and not
Oracle version 7.0 on <systemitem class="osname">AIX</> 3 uses OS-supported locks in shared <application>ecpg</application> features that these RDBMS do not
memory that allow an application designer to link an application support.
in a <quote>single tasking</quote> way. Instead of starting one client </para>
process per application process, both the database part and the
application part run in the same process. In later versions of
Oracle this is no longer supported.
</para>
<para> <variablelist>
This would require a total redesign of the <varlistentry>
<productname>PostgreSQL</productname> access model and the <term>Syntax of <command>FETCH</command></term>
performance gain does not justify the effort. <indexterm><primary>FETCH</><secondary>embedded SQL</></indexterm>
</para>
</listitem> <listitem>
</varlistentry> <para>
</variablelist> The standard syntax for <command>FETCH</command> is:
</para> <synopsis>
</sect1> FETCH <optional><replaceable>direction</></> <optional><replaceable>amount</></> IN|FROM <replaceable>cursor</replaceable>
</synopsis>
<indexterm><primary>Oracle</></>
<application>Oracle</application>, however, does not use the
keywords <literal>IN</literal> or <literal>FROM</literal>. This
feature cannot be added since it would create parsing conflicts.
</para>
</listitem>
</varlistentry>
</variablelist>
</sect1>
<sect1 id="ecpg-develop">
<title>For the Developer</title>
<para>
This section explain how <application>ecpg</application> works
internally. This information can occasionally be useful to help
users understand how to use <application>ecpg</application>.
</para>
<sect1 id="ecpg-porting"> <sect2>
<title>Porting From Other <acronym>RDBMS</acronym> Packages</title> <title>The Preprocessor</title>
<para> <para>
The design of <application>ecpg</application> follows the SQL The first four lines written by <command>ecpg</command> to the
standard. Porting from a standard RDBMS should not be a problem. output are fixed lines. Two are comments and two are include
Unfortunately there is no such thing as a standard RDBMS. Therefore lines necessary to interface to the library. Then the
<application>ecpg</application> tries to understand syntax preprocessor reads through the file and writes output. Normally
extensions as long as they do not create conflicts with the it just echoes everything to the output.
standard.
</para> </para>
<para> <para>
The following list shows all the known incompatibilities. If you When it sees an <command>EXEC SQL</command> statement, it
find one not listed please notify the developers. Note, however, that intervenes and changes it. The command starts with <command>exec
we list only incompatibilities from a precompiler of another RDBMS sql</command> and ends with <command>;</command>. Everything in
to <application>ecpg</application> and not between is treated as an <acronym>SQL</acronym> statement and
<application>ecpg</application> features that these RDBMS do not parsed for variable substitution.
support.
</para> </para>
<para> <para>
<variablelist> Variable substitution occurs when a symbol starts with a colon
<varlistentry> (<literal>:</literal>). The variable with that name is looked up
<term>Syntax of FETCH</term> among the variables that were previously declared within a
<indexterm><primary>FETCH</><secondary>embedded SQL</></indexterm> <literal>EXEC SQL DECLARE</> section. Depending on whether the
<listitem> variable is being use for input or output, a pointer to the
<para> variable is output to allow access by the function.
The standard syntax for FETCH is:
</para>
<para>
FETCH [direction] [amount] IN|FROM <replaceable>cursor</replaceable>.
</para>
<para>
<indexterm><primary>Oracle</></>
<application>Oracle</application>, however, does not use the keywords IN
or FROM. This feature cannot be added since it would create parsing
conflicts.
</para>
</listitem>
</varlistentry>
</variablelist>
</para> </para>
</sect1>
<sect1 id="ecpg-develop">
<title>For the Developer</title>
<para> <para>
This section explain how <application>ecpg</application> For every variable that is part of the <acronym>SQL</acronym>
works internally. It contains valuable information to help users query, the function gets other arguments:
understand how to use <application>ecpg</application>.
<itemizedlist>
<listitem>
<para>
The type as a special symbol.
</para>
</listitem>
<listitem>
<para>
A pointer to the value or a pointer to the pointer.
</para>
</listitem>
<listitem>
<para>
The size of the variable if it is a <type>char</type> or <type>varchar</type>.
</para>
</listitem>
<listitem>
<para>
The number of elements in the array (for array fetches).
</para>
</listitem>
<listitem>
<para>
The offset to the next element in the array (for array fetches).
</para>
</listitem>
<listitem>
<para>
The type of the indicator variable as a special symbol.
</para>
</listitem>
<listitem>
<para>
A pointer to the value of the indicator variable or a pointer
to the pointer of the indicator variable.
</para>
</listitem>
<listitem>
<para>
0
</para>
</listitem>
<listitem>
<para>
Number of elements in the indicator array (for array fetches).
</para>
</listitem>
<listitem>
<para>
The offset to the next element in the indicator array (for
array fetches).
</para>
</listitem>
</itemizedlist>
</para> </para>
<sect2> <para>
<title>The Preprocessor</title> Note that not all SQL commands are treated in this way. For
instance, an open cursor statement like
<para>
The first four lines written by <command>ecpg</command> to the output are fixed lines.
Two are comments and two are include lines necessary to interface
to the library.
</para>
<para>
Then the preprocessor reads through the file and writes output.
Normally it just echoes everything to the output.
</para>
<para>
When it sees an <command>EXEC SQL</command> statement, it
intervenes and changes it. The <command>EXEC SQL</command>
statement can be one of these:
<variablelist>
<varlistentry>
<term>Declare sections</term>
<listitem>
<para>
<command>Declare</> sections begin with:
<programlisting>
exec sql begin declare section;
</programlisting>
and end with:
<programlisting>
exec sql end declare section;
</programlisting>
In this section only variable declarations are allowed. Every
variable declared within this section is stored in a list
of variables indexed by name together with its corresponding
type.
</para>
<para>
In particular the definition of a structure or union also must
be listed inside a <command>declare</> section. Otherwise
<application>ecpg</application> cannot handle these types since
it does not know the definition.
</para>
<para>
The declaration is also echoed to the file to make it a normal
C variable.
</para>
<para>
The special types <type>VARCHAR</type> and
<type>VARCHAR2</type> are converted into a named <type>struct</> for
every variable. A declaration like:
<programlisting>
VARCHAR var[180];
</programlisting>
is converted into:
<programlisting>
struct varchar_var { int len; char arr[180]; } var;
</programlisting>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Include statements</term>
<listitem>
<para>
An include statement looks like:
<programlisting>
exec sql include filename;
</programlisting>
Note that this is NOT the same as:
<programlisting>
#include &lt;filename.h&gt;
</programlisting>
</para>
<para>
Instead the file specified is parsed by
<application>ecpg</application> so the contents of the file are
included in the resulting C code. This way you are able to
specify EXEC SQL commands in an include file.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Connect statement</term>
<listitem>
<para>
A connect statement looks like:
<programlisting>
exec sql connect to <replaceable>connection target</replaceable>;
</programlisting>
It creates a connection to the specified database.
</para>
<para>
The <replaceable>connection target</replaceable> can be specified in the
following ways:
<itemizedlist>
<listitem>
<simpara>
<literal>dbname[@server][:port][as <replaceable>connection
name</replaceable>][user <replaceable>user name</replaceable>]</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>tcp:postgresql://server[:port][/dbname][as
<replaceable>connection name</replaceable>][user <replaceable>user name</replaceable>]</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>unix:postgresql://server[:port][/dbname][as
<replaceable>connection name</replaceable>][user <replaceable>user name</replaceable>]</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>character variable</replaceable>[as
<replaceable>connection name</replaceable>][user <replaceable>user name</replaceable>]</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>character string</replaceable>[as
<replaceable>connection name</replaceable>][<replaceable>user</replaceable>]</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>default</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>user</literal>
</simpara>
</listitem>
</itemizedlist>
</para>
<para>
There are also different ways to specify the user name:
<itemizedlist>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable>/<replaceable>password</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable> identified by <replaceable>password</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal><replaceable>userid</replaceable> using <replaceable>password</replaceable></literal>
</simpara>
</listitem>
</itemizedlist>
</para>
<para>
Finally, the <replaceable>userid</replaceable> and <replaceable>password</replaceable> may be a constant text, a
character variable, or a character string.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Disconnect statements</term>
<listitem>
<para>
A disconnect statement looks like:
<programlisting>
exec sql disconnect [<replaceable>connection target</replaceable>];
</programlisting>
It closes the connection to the specified database.
</para>
<para>
The <replaceable>connection target</replaceable> can be specified in the
following ways:
<itemizedlist>
<listitem>
<simpara>
<literal><replaceable>connection name</replaceable></literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>default</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>current</literal>
</simpara>
</listitem>
<listitem>
<simpara>
<literal>all</literal>
</simpara>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Open cursor statement</term>
<listitem>
<para>
An open cursor statement looks like:
<programlisting>
exec sql open <replaceable>cursor</replaceable>;
</programlisting>
and is not copied to the output. Instead, the cursor's
<command>DECLARE</> command is used because it opens the cursor
as well.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Commit statement</term>
<listitem>
<para>
A commit statement looks like:
<programlisting>
exec sql commit;
</programlisting>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Rollback statement</term>
<listitem>
<para>
A rollback statement looks like:
<programlisting> <programlisting>
exec sql rollback; EXEC SQL OPEN <replaceable>cursor</replaceable>;
</programlisting> </programlisting>
</para> is not copied to the output. Instead, the cursor's
</listitem> <command>DECLARE</> command is used because it opens the cursor as
</varlistentry> well.
</para>
<varlistentry>
<term>Other statements</term>
<listitem>
<para>
Other <acronym>SQL</acronym> statements are used by
starting with <command>exec sql</command> and ending with
<command>;</command>. Everything in between is treated as an
<acronym>SQL</acronym> statement and parsed for variable
substitution.
</para>
<para>
Variable substitution occurs when a symbol starts with a colon
(<command>:</command>). The variable with that name is looked
up among the variables that were previously declared within a
<command>declare</> section. Depending on whether the variable is
being use for input or output, a pointer to the variable is
output to allow access by the function.
</para>
<para>
For every variable that is part of the <acronym>SQL</acronym>
query, the function gets other arguments:
<itemizedlist>
<listitem>
<para>
The type as a special symbol.
</para>
</listitem>
<listitem>
<para>
A pointer to the value or a pointer to the pointer.
</para>
</listitem>
<listitem>
<para>
The size of the variable if it is a <type>char</type> or <type>varchar</type>.
</para>
</listitem>
<listitem>
<para>
The number of elements in the array (for array fetches).
</para>
</listitem>
<listitem>
<para>
The offset to the next element in the array (for array fetches).
</para>
</listitem>
<listitem>
<para>
The type of the indicator variable as a special symbol.
</para>
</listitem>
<listitem>
<para>
A pointer to the value of the indicator variable or a pointer to the pointer of the indicator variable.
</para>
</listitem>
<listitem>
<para>
0.
</para>
</listitem>
<listitem>
<para>
Number of elements in the indicator array (for array fetches).
</para>
</listitem>
<listitem>
<para>
The offset to the next element in the indicator array (for
array fetches).
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</sect2>
<sect2>
<title>A Complete Example</title>
<para> <para>
Here is a complete example describing the output of the preprocessor of a Here is a complete example describing the output of the
file <filename>foo.pgc</filename>: preprocessor of a file <filename>foo.pgc</filename> (details may
change with each particular version of the preprocessor):
<programlisting> <programlisting>
exec sql begin declare section; EXEC SQL BEGIN DECLARE SECTION;
int index; int index;
int result; int result;
exec sql end declare section; EXEC SQL END DECLARE SECTION;
... ...
exec sql select res into :result from mytable where index = :index; EXEC SQL SELECT res INTO :result FROM mytable WHERE index = :index;
</programlisting> </programlisting>
is translated into: is translated into:
<programlisting> <programlisting>
/* Processed by ecpg (2.6.0) */ /* Processed by ecpg (2.6.0) */
/* These two include files are added by the preprocessor */ /* These two include files are added by the preprocessor */
...@@ -964,109 +1028,101 @@ exec sql select res into :result from mytable where index = :index; ...@@ -964,109 +1028,101 @@ exec sql select res into :result from mytable where index = :index;
int result; int result;
/* exec sql end declare section */ /* exec sql end declare section */
... ...
ECPGdo(__LINE__, NULL, "select res from mytable where index = ? ", ECPGdo(__LINE__, NULL, "SELECT res FROM mytable WHERE index = ? ",
ECPGt_int,&amp;(index),1L,1L,sizeof(int), ECPGt_int,&amp;(index),1L,1L,sizeof(int),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT, ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EOIT,
ECPGt_int,&amp;(result),1L,1L,sizeof(int), ECPGt_int,&amp;(result),1L,1L,sizeof(int),
ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT); ECPGt_NO_INDICATOR, NULL , 0L, 0L, 0L, ECPGt_EORT);
#line 147 "foo.pgc" #line 147 "foo.pgc"
</programlisting> </programlisting>
(The indentation in this manual is added for readability and not (The indentation in this manual is added for readability and not
something the preprocessor does.) something the preprocessor does.)
</para> </para>
</sect2> </sect2>
<sect2> <sect2>
<title>The Library</title> <title>The Library</title>
<para> <para>
The most important function in the library is The most important function in the library is
<function>ECPGdo</function>. It takes a variable number of <function>ECPGdo</function>. It takes a variable number of
arguments. Hopefully there are no computers that limit the arguments. Hopefully there are no computers that limit the number
number of variables that can be accepted by a <function>varargs()</function> function. This of variables that can be accepted by a
can easily add up to 50 or so arguments. <function>varargs()</function> function. This can easily add up to
</para> 50 or so arguments.
</para>
<para> <para>
The arguments are: The arguments are:
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term>A line number</term> <term>A line number</term>
<listitem> <listitem>
<para> <para>
This is a line number of the original line; used in error messages only. This is a line number of the original line; used in error
</para> messages only.
</listitem> </para>
</varlistentry> </listitem>
</varlistentry>
<varlistentry> <varlistentry>
<term>A string</term> <term>A string</term>
<listitem> <listitem>
<para> <para>
This is the <acronym>SQL</acronym> query that is to be issued. This is the <acronym>SQL</acronym> query that is to be issued.
It is modified by the input variables, i.e. the variables that It is modified by the input variables, i.e. the variables that
where not known at compile time but are to be entered in the where not known at compile time but are to be entered in the
query. Where the variables should go the string contains query. Where the variables should go the string contains
<literal>?</literal>. <literal>?</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term>Input variables</term> <term>Input variables</term>
<listitem> <listitem>
<para> <para>
As described in the section about the preprocessor, every input variable As described in the section about the preprocessor, every
gets ten arguments. input variable gets ten arguments.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term><parameter>ECPGt_EOIT</></term> <term><parameter>ECPGt_EOIT</></term>
<listitem> <listitem>
<para> <para>
An <type>enum</> telling that there are no more input variables. An <type>enum</> telling that there are no more input
</para> variables.
</listitem> </para>
</varlistentry> </listitem>
</varlistentry>
<varlistentry> <varlistentry>
<term>Output variables</term> <term>Output variables</term>
<listitem> <listitem>
<para> <para>
As described in the section about the preprocessor, every input variable As described in the section about the preprocessor, every
gets ten arguments. These variables are filled by the function. input variable gets ten arguments. These variables are filled
</para> by the function.
</listitem> </para>
</varlistentry> </listitem>
</varlistentry>
<varlistentry> <varlistentry>
<term><parameter>ECPGt_EORT</></term> <term><parameter>ECPGt_EORT</></term>
<listitem> <listitem>
<para> <para>
An <type>enum</> telling that there are no more variables. An <type>enum</> telling that there are no more variables.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
</para> </para>
</sect2>
<para> </sect1>
In the default mode, queries are committed only when <command>exec </chapter>
sql commit</command> is issued. <application>Ecpg</application>
also supports auto-commit of transactions via the
<option>-t</option> command-line option or via the <literal>exec
sql set autocommit to on</literal> statement. In
<literal>autocommit</literal> mode, each query is automatically
committed unless it is inside an explicit transaction block. This
mode can be explicitly turned off using <literal>exec sql set
autocommit to off</literal>.
</para>
</sect2>
</sect1>
</chapter>
<!-- Keep this comment at the end of the file <!-- Keep this comment at the end of the file
Local variables: Local variables:
......
doc/src/sgml/ref/ecpg-ref.sgml
View file @ cc4f5769
<!-- <!--
$Header: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v 1.20 2002/07/28 15:22:20 petere Exp $ $Header: /cvsroot/pgsql/doc/src/sgml/ref/ecpg-ref.sgml,v 1.21 2002/10/21 18:04:05 petere Exp $
PostgreSQL documentation PostgreSQL documentation
--> -->
<refentry id="APP-ECPG"> <refentry id="APP-ECPG">
<refmeta> <refmeta>
<refentrytitle id="app-ecpg-title"><application>ecpg</application></refentrytitle> <refentrytitle><application>ecpg</application></refentrytitle>
<manvolnum>1</manvolnum> <manvolnum>1</manvolnum>
<refmiscinfo>Application</refmiscinfo> <refmiscinfo>Application</refmiscinfo>
</refmeta> </refmeta>
<refnamediv> <refnamediv>
<refname> <refname><application>ecpg</application></refname>
<application>ecpg</application> <refpurpose>embedded SQL C preprocessor</refpurpose>
</refname>
<refpurpose>
embedded SQL C preprocessor
</refpurpose>
</refnamediv> </refnamediv>
<refsynopsisdiv> <refsynopsisdiv>
<refsynopsisdivinfo>
<date>1999-07-20</date>
</refsynopsisdivinfo>
<cmdsynopsis> <cmdsynopsis>
<command>ecpg</command> <command>ecpg</command>
<arg choice="opt">-v</arg> <arg choice="opt" rep="repeat"><replaceable>option</replaceable></arg>
<arg choice="opt">-t</arg>
<arg choice="opt">-I <replaceable>include-path</replaceable></arg>
<arg choice="opt">-o <replaceable>outfile</replaceable></arg>
<arg choice="plain" rep="repeat"><replaceable>file</replaceable></arg> <arg choice="plain" rep="repeat"><replaceable>file</replaceable></arg>
</cmdsynopsis> </cmdsynopsis>
</refsynopsisdiv> </refsynopsisdiv>
<refsect1 id="APP-ECPG-description"> <refsect1 id="APP-ECPG-description">
<title>Description</title> <title>Description</title>
<para> <para>
<application>ecpg</application> <command>ecpg</command> is the embedded SQL preprocessor for C
is an embedded SQL preprocessor for the C language and the programs. It converts C programs with embedded SQL statements to
<productname>PostgreSQL</productname>. It normal C code by replacing the SQL invocations with special
enables development of C programs with embedded SQL code. function calls. The output files can then be processed with any C
compiler tool chain.
</para> </para>
<para> <para>
Linus Tolke (<email>linus@epact.se</email>) was the <command>ecpg</command> will convert each input file given on the
original author of <application>ecpg</application> (up to version 0.2). command line to the corresponding C output file. Input files
Michael Meskes (<email>meskes@debian.org</email>) preferrably have the extension <filename>.pgc</filename>, in which
is the current author and maintainer of <application>ecpg</application>. case the extension will be replaced by <filename>.c</filename> to
Thomas Good (<email>tomg@q8.nrnet.org</email>) determine the output file name. If the extension of the input file
is the author of the last revision of the <application>ecpg</application> man page, on which is not <filename>.pgc</filename>, then the output file name is
this document is based. computed by appending <literal>.c</literal> to the full file name.
The output file name can also be overridden using the
<option>-o</option> option.
</para> </para>
</refsect1>
<refsect1>
<title>Options</title>
<para>
<application>ecpg</application> accepts the following command
line arguments:
<variablelist> <para>
<varlistentry> This reference page does not describe the embedded SQL language.
<term>-v</term> See &cite-programmer; for that.
<listitem> </para>
<para>
Print version information.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-t</term>
<listitem>
<para>
Turn on auto-commit of transactions. In this mode, each query is
automatically committed unless it is inside an explicit
transaction block. In the default mode, queries are committed
only when <command>exec sql commit</command> is issued.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-I <replaceable class="parameter">include-path</replaceable></term>
<listitem>
<para>
Specify an additional include path.
Defaults are <filename>.</filename> (current directory),
<filename>/usr/local/include</filename>, the
<productname>PostgreSQL</productname> include path which is
defined at compile time (default:
<filename>/usr/local/pgsql/include</filename>), and
<filename>/usr/include</filename>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>-o <replaceable>outfile</replaceable></term>
<listitem>
<para>
Specifies that <application>ecpg</application> should write all its output to <replaceable>outfile</replaceable>.
If no such option is given the output is written to
<filename><replaceable>name</replaceable>.c</filename>,
assuming the input file was
named <filename><replaceable>name</replaceable>.pgc</filename>.
If the input file does have the expected
<literal>.pgc</literal> suffix, then the output file will have
<literal>.pgc</literal> appended to the input file name.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">file</replaceable></term>
<listitem>
<para>
The files to be processed.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</refsect1> </refsect1>
<refsect1> <refsect1>
<title>Exit Status</title> <title>Options</title>
<para> <para>
<application>ecpg</application> returns 0 to the shell on <command>ecpg</command> accepts the following command-line
successful completion, non-zero for errors. arguments:
<variablelist>
<varlistentry>
<term><option>-c</option></term>
<listitem>
<para>
Automatically generate C code from SQL code. Currently, this
works for <literal>EXEC SQL TYPE</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-D <replaceable>symbol</replaceable></option></term>
<listitem>
<para>
Define a C preprocessor symbol.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-I <replaceable class="parameter">directory</replaceable></option></term>
<listitem>
<para>
Specify an additional include path, used to find files included
via <literal>EXEC SQL INCLUDE</literal>. Defaults are
<filename>.</filename> (current directory),
<filename>/usr/local/include</filename>, the
<productname>PostgreSQL</productname> include directory which
is defined at compile time (default:
<filename>/usr/local/pgsql/include</filename>), and
<filename>/usr/include</filename>, in that order.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-o <replaceable>filename</replaceable></option></term>
<listitem>
<para>
Specifies that <application>ecpg</application> should write all
its output to the given <replaceable>filename</replaceable>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-t</option></term>
<listitem>
<para>
Turn on autocommit of transactions. In this mode, each query is
automatically committed unless it is inside an explicit
transaction block. In the default mode, queries are committed
only when <command>EXEC SQL COMMIT</command> is issued.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>-v</option></term>
<listitem>
<para>
Print additional information including the version and the
include path.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>---help</option></term>
<listitem>
<para>
Show a brief summary of the command usage, then exit.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--version</option></term>
<listitem>
<para>
Output version information, then exit.
</para>
</listitem>
</varlistentry>
</variablelist>
</para> </para>
</refsect1> </refsect1>
<refsect1> <refsect1>
<title>Usage</title> <title>Notes</title>
<refsect2 id="APP-ECPG-preprocessing">
<title>Preprocessing for Compilation</title>
<para>
An embedded SQL source file must be preprocessed before
compilation:
<synopsis>
ecpg [ -d ] [ -o <replaceable>file</replaceable> ] <replaceable>file</replaceable>.pgc
</synopsis>
where the optional <option>-d</option> flag turns on debugging.
The <literal>.pgc</literal> extension is an
arbitrary means of denoting <application>ecpg</application> source.
</para>
<para>
You may want to redirect the preprocessor output to a log file.
</para>
</refsect2>
<refsect2 id="APP-ECPG-compiling"> <para>
<title>Compiling and Linking</title> When compiling the preprocessed C code files, the compiler needs to
be able to find the <application>ECPG</> header files in the
PostgreSQL include directory. Therefore, one might have to use the
<option>-I</> option when invoking the compiler (e.g.,
<literal>-I/usr/local/pgsql/include</literal>).
</para>
<para> <para>
Assuming the <productname>PostgreSQL</productname> binaries are in Programs using C code with embedded SQL have to be linked against
<filename>/usr/local/pgsql</filename>, you will need to compile the <filename>libecpg</filename> library, for example using the
and link your preprocessed source file: flags <literal>-L/usr/local/pgsql/lib -lecpg</literal>.
</para>
<synopsis> <para>
gcc -g -I /usr/local/pgsql/include [ -o <replaceable>file</replaceable> ] <replaceable>file</replaceable>.c -L /usr/local/pgsql/lib -lecpg -lpq The value of either of these directories that is appropriate for
</synopsis> the installation can be found out using <xref
</para> linkend="app-pgconfig">.
</refsect2> </para>
</refsect1> </refsect1>
<refsect1 id="APP-ECPG-grammar">
<title>Grammar</title>
<refsect2 id="APP-ECPG-library">
<title>Libraries</title>
<para>
The preprocessor will prepend two directives to the source:
<programlisting>
#include &lt;ecpgtype.h&gt;
#include &lt;ecpglib.h&gt;
</programlisting>
</para>
</refsect2>
<refsect2 id="APP-ecpg-declaration">
<title>Variable Declaration</title>
<para>
Variables declared within <application>ecpg</application> source code must be prepended with:
<programlisting>
EXEC SQL BEGIN DECLARE SECTION;
</programlisting>
</para>
<para>
Similarly, variable declaration sections must terminate with:
<programlisting>
EXEC SQL END DECLARE SECTION;
</programlisting>
<note>
<para>
Prior to version 2.1.0, each variable had to be declared
on a separate line. As of version 2.1.0 multiple variables may
be declared on a single line:
<programlisting>
char foo[16], bar[16];
</programlisting>
</para>
</note>
</para>
</refsect2>
<refsect2 id="APP-ECPG-errors">
<title>Error Handling</title>
<para>
The SQL communication area is defined with:
<programlisting>
EXEC SQL INCLUDE sqlca;
</programlisting>
</para>
<note>
<para>
The <literal>sqlca</literal> is in lowercase.
While SQL convention may be
followed, i.e., using uppercase to separate embedded SQL
from C statements, <literal>sqlca</literal> (which includes the <filename>sqlca.h</>
header file) <emphasis>must</> be lowercase. This is because the
EXEC SQL prefix indicates that this inclusion will be parsed by
<application>ecpg</application>.
<application>ecpg</application> observes case sensitivity
(<filename>SQLCA.h</> will not be found).
<command>EXEC SQL INCLUDE</command>
can be used to include other header files
as long as case sensitivity is observed.
</para>
</note>
<para>
The <literal>sqlprint</literal> command is used with the <literal>EXEC SQL WHENEVER</literal>
statement to turn on error handling throughout the
program:
<programlisting> <refsect1>
EXEC SQL WHENEVER sqlerror sqlprint; <title>Examples</title>
</programlisting>
and
<programlisting>
EXEC SQL WHENEVER not found sqlprint;
</programlisting>
</para>
<note>
<para>
This is <emphasis>not</emphasis> an exhaustive example of usage for
the <command>EXEC SQL WHENEVER</command> statement.
Further examples of usage may
be found in SQL manuals (e.g., <citetitle>The LAN TIMES Guide to SQL</> by
Groff and Weinberg).
</para>
</note>
</refsect2>
<refsect2 id="APP-ECPG-connecting">
<title>Connecting to the Database Server</title>
<para>
One connects to a database using the following:
<programlisting>
EXEC SQL CONNECT TO <replaceable>dbname</replaceable>;
</programlisting>
where the database name is not quoted. Prior to version 2.1.0, the
database name was required to be inside single quotes.
</para>
<para>
Specifying a server and port name in the connect statement is also
possible. The syntax is:
<synopsis>
<replaceable>dbname</replaceable>[@<replaceable>server</replaceable>][:<replaceable>port</replaceable>]
</synopsis>
or
<synopsis>
&lt;tcp|unix&gt;:postgresql://<replaceable>server</replaceable>[:<replaceable>port</replaceable>][/<replaceable>dbname</replaceable>][?<replaceable>options</replaceable>]
</synopsis>
</para>
</refsect2>
<refsect2 id="APP-ECPG-queries">
<title>Queries</title>
<para>
In general, SQL queries acceptable to other applications such as
<application>psql</application> can be embedded into your C
code. Here are some examples of how to do that.
</para>
<para>
Create Table:
<programlisting>
EXEC SQL CREATE TABLE foo (number int4, ascii char(16));
EXEC SQL CREATE UNIQUE index num1 on foo(number);
EXEC SQL COMMIT;
</programlisting>
</para>
<para>
Insert:
<programlisting>
EXEC SQL INSERT INTO foo (number, ascii) VALUES (9999, 'doodad');
EXEC SQL COMMIT;
</programlisting>
</para>
<para>
Delete:
<programlisting>
EXEC SQL DELETE FROM foo WHERE number = 9999;
EXEC SQL COMMIT;
</programlisting>
</para>
<para>
Singleton Select:
<programlisting>
EXEC SQL SELECT foo INTO :FooBar FROM table1 WHERE ascii = 'doodad';
</programlisting>
</para>
<para>
Select using Cursors:
<programlisting>
EXEC SQL DECLARE foo_bar CURSOR FOR
SELECT number, ascii FROM foo
ORDER BY ascii;
EXEC SQL FETCH foo_bar INTO :FooBar, DooDad;
...
EXEC SQL CLOSE foo_bar;
EXEC SQL COMMIT;
</programlisting>
</para>
<para> <para>
Updates: If you have an embedded SQL C source file named
<filename>prog1.pgc</filename>, you can create an executable
program using the following sequence of commands:
<programlisting> <programlisting>
EXEC SQL UPDATE foo ecpg prog1.pgc
SET ascii = 'foobar' cc -I/usr/local/pgsql/include -c prog1.c
WHERE number = 9999; cc -o prog1 prog1.o -L/usr/local/pgsql/lib -lecpg
EXEC SQL COMMIT;
</programlisting> </programlisting>
</para>
</refsect2>
</refsect1>
<refsect1 id="APP-ECPG-notes">
<title>Notes</title>
<para>
The complete structure definition MUST be listed
inside the declare section.
</para>
<para>
See the <filename>TODO</filename> file in the source for some more
missing features.
</para> </para>
</refsect1> </refsect1>
...@@ -399,7 +197,7 @@ EXEC SQL COMMIT; ...@@ -399,7 +197,7 @@ EXEC SQL COMMIT;
<para> <para>
<citetitle>PostgreSQL Programmer's Guide</citetitle> for a more <citetitle>PostgreSQL Programmer's Guide</citetitle> for a more
detailed description of the embedded SQL interface. detailed description of the embedded SQL interface
</para> </para>
</refsect1> </refsect1>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment