From: Michael Meskes

docs improvement for ecpg..

diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml
index cf7681b926e7dc5665fd4c3eacb5fa3d3417c62a..98f12979e65a7bb2a4e8c906bffb4b6d6e9522a9 100644 (file)
--- a/doc/src/sgml/ecpg.sgml
+++ b/doc/src/sgml/ecpg.sgml
@@ -45,15 +45,12 @@ queries. It takes care of all the tedious moving of information to and
 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. Most embedded SQL preprocessors I have seen and heard of make
-extensions so it is difficult to obtain portability between them
-anyway. I have not read the standard but I hope that my implementation
-does not deviate too much and that it would be possible to port programs
-with embedded SQL written for other RDBMS packages 
-to Postgres and thus
-promoting the spirit of free software.
+ 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
+possible to port programs with embedded SQL written for
+other RDBMS packages to
+Postgres and thus promoting the spirit of free
+software.
 
 
 The Concept
@@ -431,25 +428,6 @@ you are not interested in how it really works, skip this section.
 This version the preprocessor has some flaws:
 
 
-
-Preprocessor output
-
-
-The variables should be static.
-
-
-
-
-
-Preprocessor cannot do syntax checking on your SQL statements
-
-
-Whatever you write is copied more or less exactly to the Postgres and
-you will not be able to locate your errors until run-time.
-
-
-
-
 
 no restriction to strings only
 
@@ -485,51 +463,59 @@ to_date et al.
 records
 
 
-Possibility to define records or structures in the declare section
-in a way that the record can be filled from one row in the database.
+Records or structures have to be defined in the declare section.
 
-
-This is a simpler way to handle an entire row at a time.
-
 
 
 
 
-array operations
+missing statements
 
 
-Oracle has array operations that enhances speed. When implementing it in
-ecpg it is done for compatibility reasons only. For them to
-improve speed would require a lot more insight in the Postgres internal
-mechanisms than I possess.
+The following statements are not implemented thus far:
+
+
+ exec sql type
+
+
+ exec sql prepare
+
+
+ exec sql allocate
+
+
+ exec sql free
+
+
+ exec sql whenever sqlwarning
+
+
+ SQLSTATE
+
+
 
 
 
 
 
-indicator variables
+message ´no data found´
 
 
-Oracle has indicator variables that tell if a value is null or if
-it is empty. This largely simplifies array operations and provides for a
-way to hack around some design flaws in the handling of VARCHAR2
-(like that an empty string isn't distinguishable from a
-null value). I am not sure if this is an Oracle extension or part
-of the ANSI standard.
+The error message for "no data" in an exec sql insert select from statement
+has to be 100.
 
 
 
 
 
-typedefs
+sqlwanr[6]
 
 
-As well as complex types like records and arrays, typedefs would be
-a good thing to take care of.
+sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified in a SET
+DESCRIPTOR statement will be ignored.
 
 
 
-
 
 conversion of scripts