[PATCH] SQLFreeStmt deletes params, but does not reset the stmt->prepared state.

Поиск
Список
Период
Сортировка
От Oliver Freyd
Тема [PATCH] SQLFreeStmt deletes params, but does not reset the stmt->prepared state.
Дата
Msg-id m1qppj$obm$1@ger.gmane.org
обсуждение исходный текст
Ответы Re: [PATCH] SQLFreeStmt deletes params, but does not reset the stmt->prepared state.  ("Inoue, Hiroshi" <inoue@tpf.co.jp>)
Список pgsql-odbc
Hello,

In ResolveOneParam (convert.c:4586) there is code that converts boolean
'-1' to '1'. This is necessary for MS Access because it uses -1 as true
representation.

In my application, an Access 2013 frontend with a postgresql backend,
sometimes this conversion did not work, and the backend would fail like
this:

invalid input syntax for type boolean: "-1" at character 399

The statement is like this:

DELETE FROM "public"."someview" WHERE "id" = 13020
AND ... "someboolean" = '-1' ...

This does not happen always, and I've seen it only in DELETE queries,
when I try to delete a row that has a checkbox that is checked (true).
The first try always works, the second try (deleting another row) it fails.

Now this is how it fails (IMHO):

The ResolveOneParam() function relies on the correct types being
assigned to the parameters, In qb->ipdopts->parameters there is
SQLType and PGType. The SQLType is and enum that does not contain
boolean, only the PGType can be boolean.

In PGAPI_Execute() (execute.c:1025) it calls prepareParameters, where
the PGTypes are found (don't know how exactly), and put into the stmt,
as stmt->ipd->ipdf.parameters.

If the PGTypes are not 0, the query runs fine. The second time
the query is executed, the query is already prepared (stmt->prepared=5)
and the prepare step is omitted. But then the PGTypes are missing,
the bool '-1' -> '1' conversion is not done and the query fails.

It turns out Access calls SQLFreeStmt(option=SQL_RESET_PARAMS),
that does SC_free_params, so the params get deleted.

But the params contain the result of the prepare call,
so IMHO the stmt->prepared state is now wrong, the transaction is no
more prepared, so stmt->prepared should be reset to 0.

And that actually fixes the bug.


I hope this is useful, it took quite a while to track this down...

best regards,

    Oliver Freyd

-----------------------------------------------------------------------
diff --git a/statement.c b/statement.c
index da5abf5..a019d5d 100644
--- a/statement.c
+++ b/statement.c
@@ -581,6 +581,7 @@ SC_free_params(StatementClass *self, char option)
      {
          APD_free_params(SC_get_APDF(self), option);
          IPD_free_params(SC_get_IPDF(self), option);
+        if (self->prepared!=NOT_YET_PREPARED)\
SC_set_prepared(self, NOT_YET_PREPARED);
      }
      PDATA_free_params(SC_get_PDTI(self), option);
      self->data_at_exec = -1;

Вложения

В списке pgsql-odbc по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: PostgreSQL crash at SQLColAttribute()
Следующее
От: "Inoue, Hiroshi"
Дата:
Сообщение: Re: [PATCH] SQLFreeStmt deletes params, but does not reset the stmt->prepared state.