Re: Disallow Premature

Disallow Premature description added to the website.

Regards, Dave.

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 22 March 2002 00:32
> To: Henshall, Stuart - WCP
> Cc: 'pgsql-odbc@postgresql.org'
> Subject: Re: [ODBC] 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>