On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan <and...@dunslane.net> wrote: 1. I've been in discussion with some people about adding simple JSON extract > functions. We already have some (i.e. xpath()) for XML. > > 2. You might find htsql <http://htsql.org/> interesting.
My colleagues and myself have thought about this quite a lot. Even without changing any of FEBE's semantics (so far, I think they're basically fine, with the glaring problem of hidden session state) I think it may be a good time to experiment in supporting SPDY (clearly, 9.3+), which solves some of the problems of HTTP that make it pretty unusable for interactive database workload. For a long time, it looked like SPDY would become the IETF's HTTP 2.0. But the future is still clouded, as just recently Microsoft introduced their own mostly-compatible design. So that's a bit scary. More concretely, here's what I really want. The first two concerns are almost entirely technical, the latter two social, in that they rely on notion of "common" or "standard': * A standard frame extension format. For example, last I checked Postgres-XC, it required snapshot information to be passed, and it'd be nice that instead of having to hack the protocol that they could attach an X-Snapshot-Info header, or whatever. This could also be a nice way to pass out-of-band hint information of all sorts. * Something similar to the HTTP "Host" header, so that one can route to databases without having to conflate database identity with the actual port being connected to. Yes, theoretically it can be done with weird startup packet gyrations, but that is firmly in the "weird" category. * HTTP -- and *probably* its hypothetical progeny -- are more common than FEBE packets, and a lot of incidental complexity of writing routers is reduced by the commonality of routing HTTP traffic. * Protocol compression -- but a bit of sand in the gears is *which* compression -- for database workloads, the performance of zlib can be a meaningful bottleneck. Lastly, a case that can not as easily be fixed without some more thinking is leveraging caching semantics of HTTP. think people would really, really like that, if they could get away from having to hand-roll their own cache regeneration in common cases. -- fdr -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers