Thomas Lotterer wrote:
> On Tuesday, 31. July 2007 at 11:30 pm, Mark Hatle wrote:
>> Thomas Lotterer wrote:
>>> The current incomplete support for SQLite sends a false signal to
>>> those who are interested in it. Everyone should know for sure: BDB
>>> only.
>> Make a list of what is incomplete and as I have time I will attempt to
>> implement the missing feature(s).
>>
> Mark, with "incomplete" I mean the occurrences of
> 
> $ fgrep 'fprintf(stderr, "*** sql_' rpmdb/sqlite.c
> fprintf(stderr, "*** sql_associate:\n");
> fprintf(stderr, "*** sql_join:\n");
> fprintf(stderr, "*** sql_cdup:\n");
> fprintf(stderr, "*** sql_cpget:\n");
> fprintf(stderr, "*** sql_ccount:\n");

Ahh those stubs are there because they are defined in the normal db3
abstraction.. but RPM itself never uses them.  If there comes to a point
where RPM decides to use them, we can finish implementing those stubs.

> any of which is a stub that does nothing more than "return EINVAL;"

So in this case EINVAL makes sense and I think does what we want.
Perhaps we need a bit better docs to indicate these are not implemented
because they are not used by RPM.

--Mark

> With "false signal" I mean the fact that any newcomer that reads
> "supports SQLite" will surly assume a different level of support than
> key+value store. We should make this clear to users early.
> 
> But stop! Based on my current understanding of the desired level of
> SQLite support if these missing functions only add speed, not
> functionality, then there is no need to put any efforts in them. 
>