ecpg news
От | Michael Meskes |
---|---|
Тема | ecpg news |
Дата | |
Msg-id | 199802241226.NAA09111@gauss.topsystem.de обсуждение исходный текст |
Список | pgsql-hackers |
I'm back to having a working 6.3 installation since saturday night. It appears Jan's patches fixed my problem. Anyway, I've just submitted a patch that fixes all bugs I could reproduce. However, I cannot reproduce the problem with the varchar entry in a struct in test2.pgc. So if this still exists we have to dig into it in more detail. Also, I'm not sure about what the standard says for the whenever command. I'm pretty sure I already saw a 'exec whenever sqlerror break;' command maybe on Ingres. Oracle does not know about this. I tried implementing it regardless, but found that this is almost impossible since break obviously cannot be issued outside a loop resp. switch statement. Shall I just remove it? And the continue statement? Currently ecpg adds a continue command, but it appears to be better to do nothing in case the user wants to continue. This is btw what Oracle does too. Finally, here's a list of open bugs that I won't be able to tackle before 6.3 is released: - 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. - There 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 * Michael -- Dr. Michael Meskes, Project-Manager | topsystem Systemhaus GmbH meskes@topsystem.de | Europark A2, Adenauerstr. 20 meskes@debian.org | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10
В списке pgsql-hackers по дате отправления: