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.
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.
regards,
Hiroshi Inoue