Re: Disallow Premature

Disallow Premature description added to the website.

Regards, Dave.

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue(at)tpf(dot)co(dot)jp]
> Sent: 22 March 2002 00:32
> To: Henshall, Stuart - WCP
> Cc: 'pgsql-odbc(at)postgresql(dot)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(at)postgresql(dot)org
>