Skip site navigation (1) Skip section navigation (2)

Re: Disallow Premature

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: 'Hiroshi Inoue' <Inoue(at)tpf(dot)co(dot)jp>,"Henshall, Stuart - WCP" <SHenshall(at)westcountrypublications(dot)co(dot)uk>
Cc: "'pgsql-odbc(at)postgresql(dot)org'" <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Disallow Premature
Date: 2002-03-22 21:02:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
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 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

pgsql-odbc by date

Next:From: Johann ZuschlagDate: 2002-03-25 15:06:36
Subject: Warnings
Previous:From: Hiroshi InoueDate: 2002-03-22 00:39:45
Subject: Re: Disallow Premature

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group