Quick update: Re: Failure to save as postgresql database

[Jack]

On 2021.01.01 13:57, Jack wrote:
> On 2020.12.31 19:02, Jack wrote:
>> In looking at https://bugs.kde.org/show_bug.cgi?id=430163 I got both  
>> mariadb and postgresql set up.  I can save to mariadb (mysql) but  
>> not to postgresql.  The error I get is:
>> 
>> -----
>> Cannot save to current database: Error in function void  
>> MyMoneyStorageSqlPrivate::deleteKeyValuePairs(const QString&, const  
>> QVariantList&) : deleting kvp for STORAGE
>> Driver = QPSQL, Host = localhost, User = jack, Database = kmm
>> Driver Error:
>> Database Error No -1:
>> Text:
>> Error type 0
>> Executed: DELETE FROM kmmKeyValuePairs WHERE kvpType = ? AND kvpId =  
>> ?;
>> Query error No 42601: ERROR:  syntax error at or near "("
>> LINE 1: EXECUTE  ('STORAGE', '')
>>                  ^
>> (42601) QPSQL: Unable to create query
>> Error type 2  
>> /var/tmp/portage/app-office/kmymoney-5.1.9999/work/kmymoney-5.1.9999/kmymoney/plugins/sql/mymoneystoragesql_p.h:1927
>> -----
>> 
>> In that call, kvpType is "STORAGE" and idList contains one empty  
>> string.  I have no idea where the question marks in the "Executed"  
>> line come from.  I see no obvious errors in the qSql code, other  
>> than perhaps wondering if the "" is getting correctly bound to  
>> :kvpID but I know I'm grabbing at straws here.
>> 
>> My other question is where LINE 1: EXECUTE('STORAGE','') comes  
>> from.  Those would be the proper two values for the single execution  
>> of the DELETE statement, but that seems to have come from much  
>> deeper in the libraries, although I don't know if it's still within  
>> QSql orin actual Postgresql code.
>> 
>> Any suggestions on how to further troubleshoot will be appreciated,  
>> although I know my next effort will be to run under gdb.
> With a hint from TonyB, I'm beginning to think there might be a  
> problem within QSql and its Postgres innards.  The syntax error in  
> "EXECUTE  ('STORAGE', '')" appears to be the lack of a name for the  
> prepared statement.  I'll have to track down how it creates the  
> actual psql PREPARE statement from the query.prepare call.
The actual current error is  "Query error No 0: ERROR:  current  
transaction is aborted, commands ignored until end of transaction  
block"  so I'm now digging into tracking if there is a previous SQL  
call which is failing, but not triggering an explicit end to that  
transaction.