Let's get rid of premature execution - Mailing list pgsql-odbc

From Heikki Linnakangas
Subject Let's get rid of premature execution
Date
Msg-id 54C5FCA9.7020007@vmware.com
Whole thread Raw
Responses Re: Let's get rid of premature execution  (Michael Paquier <michael.paquier@gmail.com>)
List 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

Attachment

pgsql-odbc by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Coverity and Clang Static Analyzer runs
Next
From: Michael Paquier
Date:
Subject: Re: Coverity and Clang Static Analyzer runs