Re: Disallow Premature

"Henshall, Stuart - WCP" wrote:
>
> I've looked on odbc.postgresql.org but can't seem to find what disallow
> premature does. Could someone enlighten me please? :)
> Cheers,

I've added some new options but didn't add any documentaion
about it sorry. I'm happy if someone could understand my
poor explanation and add a documentation about it.

*Disallow premature* is one of the option to compensate
the lack of a server's functionality.

For example (Middleware) applications issue the following
ODBC API calls.

SQLPreapare(hstmt, "select ...", ..)

In most cases they have to know how many fields, what kind
of fields they would return and so they would issue

SQLNumResultCols and/or
SQLDescribeCols/SQLColAttribute etc.

The problem is how the psqlodbc driver answers the inquiry.
PostgreSQL hasn't provided the Prepare functionality yet
and we couldn't ask the backend about it directly.

Psqlodbc driver provides the 3 different way about it.

1) Premature execution(default).
This (implicit) option uses the fact that backends
return the field info in advance of returning result
tuples. In addtion this option assumes that the query
would be executed later exactly. When SQLNumResultCols
.. etc is called, the driver executes the query prematurely
and gets the field info(saving the result tuples also).
This is the most effective way if the query is executed
exactly later because the driver could return the saved
result exactly for the SQLExecute call. However I've seen
the cases where the queries are never called later. I've
also seen the cases where binding parameter values changed
after the premature execution(Currently the driver doesn't
detect the change). Strictly speaking the result isn't
necessarily same even when the query is executed exactly
later.

2) Parse statemnt option
The driver parse/analyzes the query by itself *first*.
*first* means that the driver couldn't always get the
complete field info and has to use the 1) or 3) after
all in some cases. This option seems to be used that
much. I need this functionality internnaly and have
found pretty many bugs. Anyway it seems neither easy,
effective nor expected.

3) Disallow premature
This option avoids 1) and get the field info as follows.

begin;(unless in a transaction)
declare cursor .. for select ...
fetch backward in ..
close ..

The driver gets the field info using the *fetch backward*
's result. The *fetch backward* command returns no row but
returns the field info. I also expected the the *fetch
backward* command returns immediately but unfortunately it
isn't always true. The 7.1 or later servers seem to return
from the *fetch backward* command immediately(thanks to Tom's
change).

regards,
Hiroshi Inoue