Skip to content

P
Postgres FD Implementation
Commit 06b8c8a8 authored by Marc G. Fournier's avatar Marc G. Fournier
Browse files
Options 

From: Michael Meskes <meskes@usa.net>

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