sql/pgwire: send empty query response instead of command complete on empty query

[maddyblue]

When sending an empty query, we respond with command complete (C), real Postgres responds with empty query (I).

[dt]

Related to #3849 so I'll combine and do both in #3853

[dt]

I guess one question is whether this is pgwire-specific or not: should we detect empty queries in pgwire and kill them early, or leave it up to the sql executor and add an "empty" value to the driver response?

[tamird]

Fixing this as pg-specific seems fine to me.

[dt]

Hm, this example has me second guessing that:

irb(main):025:0> p.exec(" ; ; ;")
=> #<PG::Result:0x007f7fe18e2ca0 status=PGRES_EMPTY_QUERY ntuples=0 nfields=0 cmd_tuples=0>

Some combination of strings.Trim might work here, but that feels dirty to me? Maybe this is better left to a real parser?

[tamird]

That's interesting; what if you do p.exec("select 1; ; ;")?

[dt]

That one is TUPLES_OK and my other test was p.exec("; ; ; BEGIN;") which is COMMAND_OK.

[tamird]

Weird. Off-topic now but what does p.exec("SELECT 1; ; ; BEGIN") return?

Anyway, yes, leave it to the parser.

[dt]

OK. Seems like anything other than all empty queries gets an ok.
conn2.exec("; ; ; BEGIN; END; ; ;") => #<PG::Result:0x007f7fe5093640 status=PGRES_COMMAND_OK ntuples=0 nfields=0 cmd_tuples=0>

[petermattis]

I'm pretty sure the parser already handles stripping out empty statements.

[dt]

Right, I think the missing piece is communicating back to the pgwire code, that after parsing, all queries were empty.

[petermattis]

Would be easier to do that if we weren't going through the sql/driver protos.

[knz]

This is likely addressed by #4081.

[dt]

@knz #4081 is our lib/pq-backed client shell. This issue is about the actual server response -- when postgres gets multiple statements that are all empty after parsing, it replies with EMPTY_QUERY, whereas we're only sending that if we have a single, trivially empty statement.