please trim the sql statement before processing it - e.g. <space>select 1 fails

[cameronbraid]

Describe the bug

Example in java

standalone repro : (uses testcontainers)

git clone https://github.com/cameronbraid/risingwave-java-received-resultset-tuples-but-no-field-structure-for-them-reproduction
cd risingwave-java-received-resultset-tuples-but-no-field-structure-for-them-reproduction
mvn test

example code :

var list = handle.createQuery(" select 1").mapToMap().list();

java.lang.IllegalStateException: Received resultset tuples, but no field structure for them
 at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2301)
 at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)
 at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:496)
 at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:413)
 at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:190)
 at org.postgresql.jdbc.PgPreparedStatement.execute(PgPreparedStatement.java:177)
 at org.jdbi.v3.core.statement.SqlLoggerUtil.wrap(SqlLoggerUtil.java:31)
 at org.jdbi.v3.core.statement.SqlStatement.internalExecute(SqlStatement.java:1787)
 at org.jdbi.v3.core.result.ResultProducers.lambda$createResultBearing$3(ResultProducers.java:94)
 at org.jdbi.v3.core.result.ResultIterable.lambda$of$0(ResultIterable.java:58)
 at org.jdbi.v3.core.result.ResultIterable.stream(ResultIterable.java:269)
 at org.jdbi.v3.core.result.ResultIterable.collect(ResultIterable.java:325)
 at org.jdbi.v3.core.result.ResultIterable.list(ResultIterable.java:314)
 at risingwave.TestCase.testCase(TestCase.java:60)
 at java.base/java.util.ArrayList.forEach(Unknown Source)
 at java.base/java.util.ArrayList.forEach(Unknown Source)

To Reproduce

No response

Expected behavior

No response

Additional context

No response

[xiangjinwu]

risingwave/src/utils/pgwire/src/pg_protocol.rs

Lines 395 to 409 in b429e9c

	async fn process_parse_msg(&mut self, msg: FeParseMessage) -> PsqlResult<()> {
	let sql = cstr_to_str(&msg.sql_bytes).unwrap();
	tracing::trace!("(extended query)parse query: {}", sql);
	// Flag indicate whether statement is a query statement.
	// TODO: regard DML with RETURNING as a query
	let is_query_sql = {
	let lower_sql = sql.to_ascii_lowercase();
	lower_sql.starts_with("select")
	|| lower_sql.starts_with("values")
	|| lower_sql.starts_with("show")
	|| lower_sql.starts_with("with")
	|| lower_sql.starts_with("describe")
	|| lower_sql.starts_with("explain")
	};

The query is actually executed correctly, but our pgwire extend query protocol is falsely telling the client "this is not a query and do not expect any output".

@ZENOTME Do you recall why it was designed to use naive string comparison rather than invoke the parser?

[ZENOTME]

Before #6849, we parse in frontend. I currently try to move parser to pgwire in extended query mode, it may more complex than simple query mode because we need to replace the parameter in parse tree.