Hi Mihia,

   Since I am using in-memory database I only have one connection. I don't
want the limiting factors to limit all stmt, only some.
Regarding pointers used in a remote process. There is no harm if one
is aware of the pointer belonging to a remote process. A handle can be
anything as long as it is unique.

Thanks,
-Alex



On Tue, Jun 3, 2008 at 2:23 PM, Mihai Limbasan <[EMAIL PROTECTED]> wrote:

> Alex Katebi wrote:
>
>> Hi All,
>>
>> For those of us that use SQLite mostly in-memory. Our context is mostly
>> not
>> {sqlite3*} database pointer, it is {sqlite3_stmt*}.
>>
>> Current API?
>>
>> int sqlite3_set_authorizer(
>>  sqlite3*,
>>  int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
>>  void *pUserData
>> );
>>
>> Can we add the following API in the future?
>>
>> int sqlite3_stmt_set_authorizer(
>>  sqlite3_stmt*,
>>  int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
>>  void *pUserData
>> );
>>
>>
>>
> Why overload the API when you could simply use sqlite3_db_handle? Pass it
> the your sqlite3_stmt* and you'll get the sqlite3 * to which your prepared
> statement belongs. You could even (ab)use the preprocessor to redefine the
> authorizer callback setter to always implicitely call sqlite3_db_handle (I
> personally dislike preprocessor magic that violates the principle of least
> astonishment, but you expect to be the sole maintainer for the code it's
> very much OK.)
>
> I have a user interface RPC for my application that configures and gets
>> status from my in-memory server database.
>>
>>
> That sounds like you are using raw pointers as handles passing them to
> remote consumers. If at all possible, I recommend you avoid this practice -
> it's terrible from a security standpoint, and it's questionable from a
> robustness standpoint. User mode pointers should be considered valid only
> within their defined domain, i.e. the address space of the process, and any
> type of pointers (including kernel pointers) should be considered valid only
> on the local machine.
>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to