Connection_lastRowId on postgresql

[Jan-Henrik Haukeland]

On 2. mai. 2008, at 09.35, Paul J Stevens wrote:

> Jan-Henrik Haukeland wrote:
>> And yes, reusing a prepared statement after it returns a result set  
>> is
>> problematic for SQLite, hence Connection_clear() was exposed.  
>> Creating
>> a new statement for the result set instead of reusing the prepared  
>> one
>> should work, but it has not been a big enough nag to refactor.
>
> It's not a big problem for me either - yet. But it does impose a  
> specific
> pattern in my code that is not evident at first glance. This is only  
> an
> issue during big loops triggering massive amounts of insert queries,
> each of which *must* return the lastrowid. But that only affects
> throughput,

Well, almost all of this would not be necessary if a workaround for  
Connection_lastRowId() on postgres could be found. This is the root  
cause and trying to find a solution for this, if possible, would be  
best.

> so it's not critical - unlike the mysql bug :-(.

Yes, the mysql bug is very bad, and a workaround *must* be found. I'll  
look into that.


> I also noticed you're using the deprecated sqlite3 interface for  
> statements,
> right? I'm asking because I'm seeing very undescriptive errors  
> raised by
> executing statements in the sqlite code: SQL logic error or missing  
> database.
>
> It looks like all that is needed is replacing sqlite3_prepare with
> sqlite3_prepare_v2. I'll do some testing today...

sqlite3_prepare_v2() was first added in SQLite version 3.3.9 and  
libzdb should work with 3.x. But you are right, using this interface,  
if available, is preferable with regards to error reporting. I'll use  
an #ifdef to add it.