RE: Error handling in ODBC - Mailing list pgsql-odbc
From | Dave Page |
---|---|
Subject | RE: Error handling in ODBC |
Date | |
Msg-id | 8568FC767B4AD311AC33006097BCD3D61A2C6D@woody.vale-housing.co.uk Whole thread Raw |
In response to | Error handling in ODBC ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
List | pgsql-odbc |
> -----Original Message----- > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp] > Sent: 20 June 2001 08:51 > To: Dave Page; 'pgsql-odbc@postgresql.org' > Subject: Re: [ODBC] Error handling in ODBC > > > I wrote: > > > > Dave Page wrote: > > > > > > > > > Perhaps I spoke too soon - a minor problem: > > > > > > Executing a more complex query gives the following notice in the > > > commlog: > > > > > > NOTICE from backend during send_query: 'NOTICE: QUERY PLAN: > > > > > > Hash Join (cost=844.62..860.22 rows=8 width=148) > > > -> Seq Scan on pg_type t (cost=0.00..6.30 rows=230 width=36) > > > -> Hash (cost=844.60..844.60 rows=8 width=112) > > > -> Nested Loop (cost=0.00..844.60 rows=8 width=112) > > > -> Seq Scan on pg_class c > (cost=0.00..833.30 rows=1 > > > width=58) > > > SubPlan > > > -> Seq Scan on pg_rewrite > (cost=0.00..3.28 > > > rows=1 > > > width=32) > > > -> Index Scan using > pg_attribute_relid_attnum_index on > > > pg_attribute a (cost=0.00..11.16 rows=11 width=54) > > > > > > ' > > > > > > However, the driver is returning the following to my test prog: > > > > > > NOTICE: QUERY PLAN: > > > > > > Hash Join (cost=844.62..860.22 rows=8 width=148) > > > -> Seq Scan on pg_type t (cost=0.00..6.30 rows=230 width=36) > > > -> Hash (cost=844.60..844.60 rows=8 width=112) > > > -> Nested Loop (cost=0.00..844.60 rows=8 width=112) > > > -> Seq Scan on pg_class c > (cost=0.00..833.30 rows=1 > > > width=58) > > > SubPlan > > > -> Seq Scan on pg_rewrite > (cost=0.00..3.28 > > > rows=1 > > > width=32) > > > -> Index Scan using > pg_attribute_relid_attnum_index on p > > > 00000 ????????????? ? ? ?? > > > 64 Query Plan > > > > > > I couldn't see any obvious cause for this in the code, > but as I've > > > said before, I'm not that familiar with it. I've included my test > > > code below BTW incase I'm doing something stupid. > > > > > > > The length of the NOTICE message may exceed the buffer size > prepared > > by the caller of SQLError() though I'm not sure. > > The driver manager seems to set the buffer size to 512 even > though we set the size bigger. The following seems to be needed. Ok, I can code around that in my apps. > > I'm not sure about the spec of SQLError() but it seems hard > to return > > a large error message at once. I would change the driver to > return a > > large error message by multiple SQLError calls. You seem to have to > > call SQLError() until it returns SQL_NO_DATA. > > > > > On a slightly different note, I also noticed in connection.c that > > > there is a CC_send_function function that I didn't notice before. > > > This has the same sort of message processing loop in it as > > > CC_send_query, but doesn't look like it will process notices > > > correctly either. > > > > > > > OK I would take care of this also. > > > > Hmm CC_send_function seems to be only for large objects. > I would postpone this, sorry. Not a problem with me, I don't use large objects. I only pointed it out in case it was a problem that might affect others. Let me know when you think we're ready to package the 07.01.0006.... regards, Dave.
pgsql-odbc by date: