| From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> | 
|---|---|
| To: | "Scot Loach" <sloach(at)sandvine(dot)com>, <pgsql-odbc(at)postgresql(dot)org> | 
| Subject: | Re: change to error result in SQLStatistics | 
| Date: | 2004-10-05 08:40:20 | 
| Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E43068E8@ratbert.vale-housing.co.uk | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-odbc | 
> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org 
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Scot Loach
> Sent: 05 October 2004 04:19
> To: pgsql-odbc(at)postgresql(dot)org
> Subject: [ODBC] change to error result in SQLStatistics
> 
> info.c version 1.106 changes the semantics of 
> PGAPI_Statistics.  If a table name is passed in and the table 
> does not exist, the function previously returned SQL_ERROR, 
> it now returns SQL_SUCCESS.
Hi Scot,
My best guess is that it is an attempt to prevent errors occuring on
zero column tables, such as one that inherits other tables. It cannot
currently tell whether a table exists or not however, because it uses
SQLColumns which can return SQL_SUCCESS when used with a search pattern
that doesn't match any tables (I'm not entirely convinced that is
correct, but as noone has ever complained, I don't think it should be
changed). I guess the simple answer is to add a check for the table at
the beginning of the function and return an error there if required.
Any other thoughts?
Regards, Dave
| From | Date | Subject | |
|---|---|---|---|
| Next Message | anthony.caduto | 2004-10-05 14:06:32 | Re: Access and PG ODBC problem | 
| Previous Message | Dave Page | 2004-10-05 07:45:12 | Re: Access and PG ODBC problem |