Handle DEALLOCATE ALL and DISCARD ALL for prepared statements

[knizhnik]

This implements a hacky/clever approach of handling the DEALLOCATE ALL and DISCARD ALL SQL statements. Instead of parsing the queries themselves, which PgBouncer avoids doing completely, this parses the CommandComplete packet returned by the server.

Fixes prisma/prisma#21635
Fixes #974

[JelteF]

I think supporting DEALLOCATE ALL is a worthy effort. It currently silently breaks the whole server. And because there is no protocol level equivalent, all clients that want send this need to send it as SQL.

When I saw the title of this PR I thought I was going to hate it, because I'd expect it to implement a very simple query parser. And I was happily surprised that's not what's going on. Instead it's using the command tag from the CommandComplete packet. And I actually think that idea is quite elegant, since the command tags are well defined by postgres and easy to parse (as opposed to SQL which can have comments or extra spaces or lowercase). So I quite like this general approach. I left some comments on changes that should be done to make this handle some more edge cases.

Also this needs some tests. And docs need to be updated that we now actually do support DEALLOCATE ALL

[janpio]

I have just opened #974, which explains the problem and thus motivation behind such a change a bit more.

Great to see there is already a PR aiming to fix this problem! 💚

[JelteF]

Code looks good. All it now needs is a test.

[JelteF]

Also CI is complaining about the codeformatting. make format should fix that.

[petere]

While this is not "query parsing", it still assumes semantics about the contained SQL commands that are not part of the protocol specification. How might this affect non-PostgreSQL uses of PgBouncer.

[JelteF]

How might this affect non-PostgreSQL uses of PgBouncer.

To be clear, you're talking about other databases that use the Postgres protocol, but don't speak Postgres its SQL dialect, right? If so, then (tl;dr) I think the impact would be negligable.

The "CommandComplete parsing" here would only have any impact in practice if the server responded with DISCARD ALL/DEALLOCATE ALL to a query. While not a strict requirement the protocol description of the CommandComplete packet indicates that this really only should be done when a DEALLOCATE ALL/DISCARD ALL query was sent:

The command tag. This is usually a single word that identifies which SQL command was completed.

While in theory it's possible that some other non-PostgreSQL server implements a DEALLOCATE ALL/DISCARD ALL command with different semantics than Postgres, it seems rather unlikely that in practice such different semantics would not include clearing of the prepared statements. Especially because there's no protocol level message that can be used for the purpose of clearing all prepared statements. So in practice I don't think this would impact anyone badly.