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  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Coverity and Clang Static Analyzer runs
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Coverity and Clang Static Analyzer runs