[ISSUE] Acra is not parsing inserts ending in 'RETURNING 0'

[Machado117]

Describe the bug When I run an INSERT query ending in RETURNING 0 with encryption turned on for one of the the fields, acra does not encrypt the field. The following message can be found on acra logs: time="2022-09-23T09:39:36Z" level=error msg="Error occurred on query handler" client_id=testfdz code=900 error="invalid returning format provided" proxy=client session_id=8 If I run the query as a JDBC batch the entry is not inserted at all.

To Reproduce Steps to reproduce the behavior:

• Executing a query
  1. Run the following query INSERT INTO mytable (name, age) VALUES ('John', 25) RETURNING 0;
• JDBC Batch code

  
  import java.sql.*;

public class AcraCrash {

public static void main(String[] args) throws Exception {
    Class.forName("org.postgresql.Driver");
    String url = "jdbc:postgresql://localhost:9393/testdb";
    Connection conn = DriverManager.getConnection(url, "postgres", "postgres");
    PreparedStatement st = conn.prepareStatement("INSERT INTO mytable (name, age) VALUES (?, ?) returning 0");
    conn.setAutoCommit(false);

    st.setCharacterStream(1, new StringReader("John"));
    st.setInt(2, 25);
    st.addBatch();

    st.executeBatch();

    conn.commit();

    st.close();
    conn.close();
}

}

**Expected behavior**
The query should be inserted with the value encrypted

**Acra configuration files**
    - [ ] `encryptor_config.yaml`

• table: mytable columns:
  • name
  • age encrypted:
  • column: name data_type: str

Environment (please complete the following information):

• Acra version: de034708d001e24728e077077e789b1499df9bbd
• Database server and its version: PostgreSQL 9.6.10
• Installed components:
  • [ ] AcraServer
• Data-in-transit encryption between Acra and the client-side application:
  • [ ] no transport encryption
• Installation way:
  • [ ] via Docker

[Lagovas]

Thanks for the issue and found error case. I reproduced this case and will fix it it soon. Now, AcraServer handles returning clauses only with column names in the list and doesn't accept literals. We will change it to be more compatible with SQL syntax.

[Machado117]

Ok, thanks!

[Lagovas]

Hi. We fixed this problem in recent PR #584. It is already in master.

[Machado117]

Seems to be working. Thanks for the fix!