Re: 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.

> 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.

regards,
Hiroshi Inoue