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

Re: New release

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Joost Kraaijeveld" <J(dot)Kraaijeveld(at)Askesis(dot)nl>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: New release
Date: 2005-02-10 11:57:30
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4528A7F@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: pgsql-odbc
 

> -----Original Message-----
> From: Joost Kraaijeveld [mailto:J(dot)Kraaijeveld(at)Askesis(dot)nl] 
> Sent: 10 February 2005 10:58
> To: Dave Page
> Subject: RE: [ODBC] New release
> 
> Hi Dave,
> 
> Dave Page schreef:
> >> The patch has changed the behaviour but now it tries to look
> >> for the argument of the function in the pg_class table, see
> >> below for the relevant trace output.
> > 
> > OK, the attached patch works for me, with simple queries to
> > those with a
> > mix of functions and tables, and with quotes aliases
> > containing spaces!
>
> Regarding the function lookup it works OK. My problem is not 
> solved thought :-(. A double problem is that I have no access 
> to the source of the client application but only a log file 
> (it is a 4GL generated Clarion application).
> 
> I think I have found the problem with the query.
> 
> According to 
> http://gborg.postgresql.org/project/psqlodbc/genpage.php?doc-c
> onfig the driver will fallback to actually executing the 
> query is it cannot determine the requested values. The 
> clientapplication does a "SQLColAttribute" to get the number 
> of columns in the query. Because the parse_statement function 
> basically does nothing for a function,  irdflds->nfields is 1 
> and stmt->ntab is 0, so stmt->parse_status is set to to 
> STMT_PARSE_FATAL and the function returns FALSE. The calling 
> function (PGAPI_ColAttributes) does not check the return 
> value and assumes that irdflds->fields contains a valid 
> number of columns (line 474) and returns the value instead of 
> falling back to executing the statement. The client 
> application now thinks that there are 0 columns which it 
> faithfully displays, while I was expecting to see 9 values in 
> a report.

Urgh. In which case this will need some major rewriting to look for and
note functions as well as tables so that it can properly expand '*'. To
make matters worse, there may well be different functions with the same
name (foo(int4) returning SETOF foo, foo(float) returning SETOF bar
etc), meaning that we also need to figure out the data types of the
parameters passed to the function in the same way the backend does.

Unfortunately I'm afraid I simply don't have the time to even begin to
try to figure out that lot :-(
 
> Than another question :
> 
> I do not understand however if, or how the above problem can 
> lead to a "The cursor is open" error (see the attached zip 
> file with the full logfile). Is this possible or is this just 
> the second problem?

I honestly don't know :-(

Sorry I cannot be of more help.

Regards Dave.

pgsql-odbc by date

Next:From: Paul CochraneDate: 2005-02-10 12:05:59
Subject: Re: Compiling using Visual Studio 2003
Previous:From: Joost KraaijeveldDate: 2005-02-10 11:26:56
Subject: Re: Compiling using Visual Studio 2003

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