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:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Error handling in ODBC
Next
From: Christian Bucanac
Date:
Subject: RE: slow performance postgres 7.0.3 and odbc