This list is still from Linus. MM

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 postgres95 and you will not be
able to locate your errors until run-time.
    
No restriction to strings only 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 cases, like when the data contains the null character,
this will be a serious problem.

There should be different error numbers for the different errors instead of
just -1 for them all.
    
Missing library functions to_date et al.
    
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.
    
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.
    
As well as complex types like records and arrays, typedefs would be a good
thing to take care of.
    
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. The functionality could be accomplished with some conversion
scripts. Speed will never be accomplished in this way. To do this you need a
bigger insight in the database construction and the use of the database than
could be realised in a script.

Now comes my list (MM):

What do we do with enum data types?

'signed' isn't understood so far
