Thread: Disallow Premature
I've looked on odbc.postgresql.org but can't seem to find what disallow premature does. Could someone enlighten me please? :) Cheers, - Stuart
"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
Hiroshi Inoue wrote:
>
> "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,
[snip]
> 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
^^^^^
doesn't seem
Sorry.
> much. I need this functionality internnaly and have
> found pretty many bugs. Anyway it seems neither easy,
> effective nor expected.
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 >