Thread: New release
Per Peter's recent suggestion, I will bundle up a new formal release of psqlODBC in the next couple of days. So, just in case, does anyone have any patches to submit beforehand? Regards, Dave.
Hi Dave, pgsql-odbc-owner@postgresql.org schreef: > Per Peter's recent suggestion, I will bundle up a new formal release > of psqlODBC in the next couple of days. So, just in case, does anyone > have any patches to submit beforehand? If someone can help me with understanding what the ODCB driver is doing I can try to find the solution for my problem asmailed earlier. This is really a showstopper problem for my application, so I really would like it to finish within thenext couple of days. Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: J.Kraaijeveld@Askesis.nl web: www.askesis.nl
> -----Original Message-----
> From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.nl]
> Sent: 08 February 2005 09:03
> To: Dave Page; pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] New release
>
> If someone can help me with understanding what the ODCB
> driver is doing I can try to find the solution for my problem
> as mailed earlier. This is really a showstopper problem for
> my application, so I really would like it to finish within
> the next couple of days.
Basically the driver doesn't understand functions in the FROM clause of
a query, and just assumes they are relations in pg_class. The patch
below works around this by simply ignoring the token altogether if there
is a bracket following it. This isn't ideal, but then we currently
ignore functions in the select list anyway from what I can see.
If you need a .dll to test, please let me know. Barring any objections,
I'll apply this in a day or two.
Regards, Dave
Index: parse.c
===================================================================
RCS file: /usr/local/cvsroot/psqlodbc/psqlodbc/parse.c,v
retrieving revision 1.47
diff -u -r1.47 parse.c
--- parse.c 21 Jul 2004 12:29:58 -0000 1.47
+++ parse.c 8 Feb 2005 15:23:41 -0000
@@ -682,9 +682,28 @@
if (!dquote)
{
if (token[0] == '(' ||
- token[0] == ')')
+ token[0] == ')')
continue;
+
+ /*
+ * Detect a function call that
looks like a table, eg.
+ * SELECT * FROM version()
+ *
+ * This needs work to properly
handle functions found in the from
+ * clause, but this at least
prevents nasty errors for now.
+ *
+ * DJP, 2005-01-08
+ */
+ if (ptr[0] == '(')
+ {
+ mylog("**** got function
= '%s%s'\n", token, ptr);
+ mylog("FIXME: functions
in the FROM clause are currently ignored!!\n");
+ continue;
+ }
}
+
+
+
if (!(stmt->ntab % TAB_INCR))
{
ti = (TABLE_INFO **) realloc(ti,
(stmt->ntab + TAB_INCR) * sizeof(TABLE_INFO *));
> -----Original Message----- > From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.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.
> -----Original Message----- > From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.nl] > Sent: 12 February 2005 10:15 > To: Dave Page > Subject: RE: [ODBC] New release > > Hi Dave, > > Attached a makefile (the patch is as big a the makefile) that > allows VC to both build a release and a debug version. > > Changes: > - Paths to seperate debug output directories are set > - Added a missing "\" after "$(INTDIR)\win_md5.obj" in the > debug section Err, OK - not sure why the patch is so bit (line end problem perhaps? I committed a fix based on what was originally in there (it must have got removed in error). > Question: do we really need the win_md5.c file? It hinders > compilation with Eclipse "Managed Make Project" and the file > can be replaced with appropriate -D options. What's Eclipse? And I'm not sure what D option you mean - cl.exe uses D for defining macros. > BTW: the drivers compiles OK with MinGW. Is there any > interest in a MinGW based Eclipse Project or simple makefile? I was thinking that we could start building purely in Mingw now that the backend does. The preferred way would be to use the existing autoconf build systems (as used on Unix). I haven't had a chance to try yet, but if you want to, please do. Regards, Dave.
> -----Original Message----- > From: Joost Kraaijeveld [mailto:J.Kraaijeveld@Askesis.nl] > Sent: 13 February 2005 19:01 > To: Dave Page > Subject: RE: [ODBC] New release > > > And I'm not sure what D option you mean - > > cl.exe uses D for defining macros. > So do I ;-). For some reason inoue created the file win_md5.c > as a wrapper around the macros MD5_OSBC and FRONTEND. I think > it should be removed because it introduces a platform > dependant file that can be replaced by compiler flags. And it > hinders Eclipse in compiling every C file in the directory > (becaus md5.c cannot be compiled) Well, I don't much care either way, but obviously Hiroshi did. However, supporting another development environment is reason enough to override one persons personal taste imho (even if that environment is a little broken ;-) ), so please feel free to submit a patch to the list. > > >> BTW: the drivers compiles OK with MinGW. Is there any > >> interest in a MinGW based Eclipse Project or simple makefile? > > > > I was thinking that we could start building purely in Mingw > > now that the backend does. The preferred way would be to > use the existing autoconf > > build systems (as used on Unix). I haven't had a chance to > try yet, but > > if you want to, please do. > I have a working makefile (attached). It compiles the driver > but for some reason it does not work (I think it has to do > with the resource file). It's not a makefile we need, but appropriate changes to the autoconf code to allow it to detect and use the Windows driver manager instead of iodbc/unixodbc. Regards Dave.