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.
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