From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Damir Simunic <damir(dot)simunic(at)wa-research(dot)ch>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal: http2 wire format |
Date: | 2018-03-28 16:03:49 |
Message-ID: | 20180328160349.zt3h56hblizvn3p6@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-03-28 16:29:37 +0800, Craig Ringer wrote:
> > - allow *streaming* of large datums
>
> Yes, very much +1 there. That's already on the wiki. Yeah:
>
> * Permit lazy fetches of large values, at least out-of-line TOASTED values
> http://www.postgresql.org/message-id/53FF0EF8.100@2ndquadrant.com
That's not necessarily the same though. What I think we need is the
ability to have "chunked" encoding with *optional* length for the
overall datum. And then the backend infrastructure to be able to send
*to the wire* partial datums. Probably with some callback based
StringInfo like buffer.
> - nested table support
> >
> >
> Can you elaborate on that one?
Nested recordsets. E.g. a SRF or procedure returning multiple query results.
> * room for other resultset formats later. Like Damir, I really want to add
> protobuf or json serializations of result sets at some point, mainly so we
> can return "entity graphs" in graph representation rather than left-join
> projection.
-1. I don't think this belongs in postgres.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-03-28 16:09:27 | Re: Proposal: http2 wire format |
Previous Message | Alvaro Herrera | 2018-03-28 15:38:02 | Re: [HACKERS] [PATCH] Incremental sort |