Re: Disallow Premature - Mailing list pgsql-odbc

"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