On Thu, Feb 11, 2021 at 12:07 PM Tom Lane <
tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <
robertmhaas@gmail.com> writes:
> > On Thu, Feb 11, 2021 at 9:42 AM Jonah H. Harris <
jonah.harris@gmail.com> wrote:
> >> As Jan said in his last email, they're not proposing all the different
> >> aspects needed. In fact, nothing has actually been proposed yet. This
> >> is an entirely philosophical debate. I don't even know what's being
> >> proposed at this point - I just know it *could* be useful. Let's just
> >> wait and see what is actually proposed before shooting it down, yes?
>
> > I don't think I'm trying to shoot anything down, because as I said, I
> > like extensibility and am generally in favor of it. Rather, I'm
> > expressing a concern which seems to me to be justified, based on what
> > was posted. I'm sorry that my tone seems to have aggravated you, but
> > it wasn't intended to do so.
>
> Likewise, the point I was trying to make is that a "pluggable wire
> protocol" is only a tiny part of what would be needed to have a credible
> MySQL, Oracle, or whatever clone. There are large semantic differences
> from those products; there are maintenance issues arising from the fact
> that we whack structures like parse trees around all the time; and so on.
> Maybe there is some useful thing that can be accomplished here, but we
> need to consider the bigger picture rather than believing (without proof)
> that a few hook variables will be enough to do anything.
>
Just to don't miss the point, creating a compat protocol to mimic others (TDS,
MySQL, etc) is just one use case.
There are other use cases to make wire protocol extensible, for example for
telemetry I can use some hooks to propagate context [1] and get more detailed
tracing information about the negotiation between frontend and backend and
being able to implement a truly query tracing tool, for example.
Another use case is extending the current protocol to, for example, send more
information about query execution on CommandComplete command instead of
just the number of affected rows.
About the HTTP protocol I think PG should have it, maybe pure HTTP (no REST,
just HTTP) because it's the most interoperable. Performance can still be very good
with HTTP2, and you have a huge ecosystem of tools and proxies (like Envoy) that
would do wonders with this. You could safely query a db from a web page (passing
through proxies that would do auth, TLS, etc). Or maybe a higher performing gRPC
version (which is also HTTP2 and is amazing), but this makes it a bit more difficult
to query from a web page. In either case, context propagation is already built-in, and
in a standard way.
Regards,
--
