49 lines
2.2 KiB
Plaintext
49 lines
2.2 KiB
Plaintext
|
This list is still from Linus. MM
|
||
|
|
||
|
The variables should be static.
|
||
|
|
||
|
The preprocessor interface is strange, to say the least It would be better
|
||
|
with a consistant unix arguments interface, perhaps builtin default
|
||
|
filenames so they won't have to be given all the time.
|
||
|
|
||
|
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.
|
||
|
|
||
|
Possibility to define records or structs in the declare section in a way
|
||
|
that the record can be filled from one row in the database. This is a
|
||
|
simpler way to handle an entire row at a time.
|
||
|
|
||
|
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.
|
||
|
|