On Thu, Jun 23, 2016 at 1:50 PM, Greg Stark <stark@mit.edu> wrote:
> On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton <f.v.anton@gmail.com> wrote:
>>
>> I'd love to talk more about this.
>
> I thought quite a bit about this a few years ago but never really
> picked up it to work on.
>
> Another option would be to allow the output of your select query to be
> read in a protobuf. That might be a feature to add in libpq rather
> than in the server, or perhaps as a new protocol feature that libpq
> would then just switch to which might make it easier to use from other
> languages. That might make it easier to use Postgres as a data store
> for an environment where everything is in protobufs without losing the
> full power of SQL schemas in the database.
I agree on this one, I think it's the most /natural/ way of doing things.
> As an aside, have you seen Cap’n Proto? It looks more interesting to
> me than protobufs. It fixes a lot of the corner cases where protobufs
> end up with unbounded computational complexity and seems a lot
> cleaner.
I've seen it around for quite some time, but my fear is that it is not
(yet?) widely adopted. Protocol Buffers themselves are not that
popular, let alone Cap'n Proto. By the way, there's also the newer
FlatBuffers[1] project, from Google too. They seem a lot like Cap'n
Proto, though. I think it's doable to provide some sort of abstraction
for these protocols in PostgreSQL, so that it can support all of them
eventually, with minimum effort for adding a new one. However, I am
skeptical about the practical advantages of having /all/ of them
supported.
--
Flavius
[1] https://github.com/google/flatbuffers