On Thu, Jun 23, 2016 at 8:15 PM, Flavius Anton <f.v.an...@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. There are different use cases where this could be useful and different approaches that could be useful for the different use cases. One idea was to have a protocol buffer data type which used the typmod as an identifier to specify the schema. Perhaps as an oid primary key from some other table, or something like how enums are handled. That would be used much like JSON is used by languages where that's natural but might be useful if you're in an environment where data is being provided in protobufs and you need to send them on in protobufs. 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. 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 haven't thought about it much but I wonder if it would be possible to actually use Cap'n Proto capabilities to grant access to Postgres RLS labels too. -- greg -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers