Tracking issue: Pgwire Client(Frontend) API

[sunng87]

As we already have a solid backend API, I'm starting to build a client API with similar granularity with our current backend API. Hopefully with this API we will be able to build the proxy framework on top of pgwire.

Tasks:

• Tokio
  • Tokio client message codec
  • Tokio client
  • TLS client
  • connection management, reconnect
• API
  • startup api
    • authentication mechanisms
      • cleartext
      • to be added
  • request-response style apis
    • simple query
    • extended query
  • callback style apis
    • notification

[Lilit0x]

Hi @sunng87, is this on the priority list, orare there other issues or features that are needed before this? What of #80?

[sunng87]

Hello @Lilit0x , this is currently stalled because I was struggling with a good API design for extended query. #250 Also since I don't have a real world use case for my own projects, so it's not in priority for me.

But if you are interested in this part, feel free to pick it up. I still think a programmable postgres proxy is very promising topic in data world. And this is the foundation of that.
The startup and simple query APIs are already done.

[Lilit0x]

I'm trying to see what addition will be more appropriate, (in the sense that what will directly affect the users of pgwire), to work on for now. In the status on the readme, I see that streaming and logical replication are yet to be implemented in the backend APIs. That'll have a.more direct impact on those that use pgwire in applications like databases, right?
I don't know if you understand what I'm saying.

[sunng87]

I see. The replication protocols are completely independent features that doesn't blocked anything from current pgwire applications. Implementing it may add more use-cases for pgwire related to data replication.

Another topic we would like to invest is providing a higher level API for cancellation, that can be used in datafusion-postgres. It requires some level of session management. I hope it can be optional and generic enough.

[Lilit0x]

That's interesting. Could you give more details? When I looked through the cancel API in pgwire, I see that it is already fully implemented, or am I missing something?

[sunng87]

@Lilit0x I have created #370 for that. We can move discussion there.

[Tpt]

It might be nice to return query rows as a Steam instead of a Vec in case the number of returned rows is high. This might be especially convenient for proxies to avoid buffering the full result set. Glad to open an MR for it if considered useful.

[sunng87]

@Tpt Sure. Please make a MR for that.