Let's get rid of premature execution
От | Heikki Linnakangas |
---|---|
Тема | Let's get rid of premature execution |
Дата | |
Msg-id | 54C5FCA9.7020007@vmware.com обсуждение исходный текст |
Ответы |
Re: Let's get rid of premature execution
|
Список | pgsql-odbc |
Hi, Under some circumstances, the driver currently does so-called "premature execution". This means that when the application does something like this: SQLPrepare("SELECT function()"); SQLNumResultCols(); but does not run SQLExecute(), the driver executes the statement anyway. This is documented, and there's an option to disable this (DisallowPremature=1), and it only happens with UseServerSidePrepare=0, and only with statements starting with SELECT, but IMHO it's nevertheless scary as hell. Currently, with DisallowPremature=1, the driver simply does not return any information for calls like SQLNumResultCols() that are called before SQLExecute(). I propose changes to this: 1. The driver should never do premature execution. That's just evil. Remove DisallowPremature option. 2. When SQLNumResultCols() is called before SQLExecute(), the driver will parse and describe the query in the server, even if UseServerSidePrepare=0. This does not affect how the query will be executed later. In the query that is sent to the server, the parameter markers are replaced with NULLs, similar to how they are replaced with the real values later when the query is executed. (This code exists already; we did the same thing in DisallowPremature mode when we sent the "dummy cursor" query, e.g. "BEGIN; DECLARE foo CURSOR FOR <real query>; FETCH 1 backwards;"). Patch attached. This simplifies the code a little bit, removes the scary premature execution, and allows us to always return column information before SQLExecute(). The Parse + Describe didn't work before protocol version 3, but we already decided that we already dropped support for version 2 in commit 341a6fcc. - Heikki
Вложения
В списке pgsql-odbc по дате отправления: