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 PostgreSQL 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): The return code is alway -1 in case of an error. You cannot see which error occured by examining the return code. The cursor is opened when the declare statement is issued. ecpg does not understand enum datatypes. The is no exec sql prepare statement. The complete structure definition has to be listed inside the declare section for ecpg to be able to understand it. Each variable has to be defined on a line on its own. There is no way yet to fill a complete array with one call except arrays of [unsigned] char which are considered strings. ecpg cannot use pointer variables except [unsigned] char *