Обсуждение: 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.
The diff & comments from this checkin are pasted at the bottom of this message. The comments don't seem to indicate
thatthis result of the change was intentional. However I'm not exactly sure what the correct behavior is according to
thespec.
Suggestions? Leave it as is or return it to its previous behavior?
scot.
@@ -2624,24 +2638,26 @@ PGAPI_Statistics(
result = PGAPI_Fetch(hcol_stmt);
}
- if (result != SQL_NO_DATA_FOUND || total_columns == 0)
+ PGAPI_FreeStmt(hcol_stmt, SQL_DROP);
+ hcol_stmt = NULL;
+ if (result != SQL_NO_DATA_FOUND)
{
- SC_full_error_copy(stmt, col_stmt); /* "Couldn't get column
- * names in
- * SQLStatistics."; */
- PGAPI_FreeStmt(hcol_stmt, SQL_DROP);
- goto SEEYA;
-
+ SC_full_error_copy(stmt, col_stmt);
+ goto cleanup;
+ }
+ if (total_columns == 0)
+ {
+ /* Couldn't get column names in SQLStatistics.; */
+ ret = SQL_SUCCESS;
+ goto cleanup;
}
-
- PGAPI_FreeStmt(hcol_stmt, SQL_DROP);
/* get a list of indexes on this table */
result = PGAPI_AllocStmt(stmt->hdbc, &hindx_stmt);
if ((result != SQL_SUCCESS) && (result != SQL_SUCCESS_WITH_INFO))
{
SC_set_error(stmt, STMT_NO_MEMORY_ERROR, "PGAPI_AllocStmt failed in SQLStatistics for indices.");
- goto SEEYA;
+ goto cleanup;
}
indx_stmt = (StatementClass *) hindx_stmt;
1) Correct the handling of SQL_C_ULONG (for *nix).
2) Prevent plan deallocation errors when the transaction
is in abort status.
3) Avoid a connection failure when notice message arrives.
4) Improve the handling of mutex(critical section).
5) Correct the cursor open check.
6) Change the Unicode driver to set the NULL terminator
of SQL_C_WCHAR type data properly.
7) Add some m(re)alloc error check.
8) Add proper cleanup steps for some functions.
9) Return proper min & max scale for timestamp data type.
10) Return proper scale for timestamp data fields.
11) Fix the bug that .009 numeric generates .9 output. (George A.J)
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Scot Loach > Sent: 05 October 2004 04:19 > To: pgsql-odbc@postgresql.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
I agree with your suggestion to check that the table exists at the beginning of PGAPI_Statistics().
What would you suggest as a query to do this?
for example - I can do the following query -
"select relname from pg_class where relname = 'elem_portstats';"
and do an Fetch, and return an error if there are no results.
scot.
-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org]On Behalf Of Dave Page
Sent: Tuesday, October 05, 2004 4:40 AM
To: Scot Loach; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] change to error result in SQLStatistics
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Scot Loach
> Sent: 05 October 2004 04:19
> To: pgsql-odbc@postgresql.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
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
> -----Original Message----- > From: Scot Loach [mailto:sloach@sandvine.com] > Sent: 05 October 2004 15:16 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] change to error result in SQLStatistics > > I agree with your suggestion to check that the table exists > at the beginning of PGAPI_Statistics(). > > What would you suggest as a query to do this? > > for example - I can do the following query - "select relname > from pg_class where relname = 'elem_portstats';" > > and do an Fetch, and return an error if there are no results. Well, we'd need some schema filtering in there, along the same lines as is already there for the main part of the function (I've not entirely deciphered the logic in there yet), but that's essentially it. Are you volunterring to give it a go? :-) Regards, Dave.
yes, I'll do the patch, I should have it done this week. scot. -----Original Message----- From: Dave Page [mailto:dpage@vale-housing.co.uk] Sent: Tuesday, October 05, 2004 10:28 AM To: Scot Loach; pgsql-odbc@postgresql.org Subject: RE: [ODBC] change to error result in SQLStatistics > -----Original Message----- > From: Scot Loach [mailto:sloach@sandvine.com] > Sent: 05 October 2004 15:16 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] change to error result in SQLStatistics > > I agree with your suggestion to check that the table exists > at the beginning of PGAPI_Statistics(). > > What would you suggest as a query to do this? > > for example - I can do the following query - "select relname > from pg_class where relname = 'elem_portstats';" > > and do an Fetch, and return an error if there are no results. Well, we'd need some schema filtering in there, along the same lines as is already there for the main part of the function (I've not entirely deciphered the logic in there yet), but that's essentially it. Are you volunterring to give it a go? :-) Regards, Dave.
> -----Original Message----- > From: Scot Loach [mailto:sloach@sandvine.com] > Sent: 05 October 2004 15:44 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] change to error result in SQLStatistics > > yes, I'll do the patch, I should have it done this week. > :-) Thanks. Regards, Dave.