Hello Vladimir,
>> Personally I think raw data bytes are OK if functions for getting all
>> keys and values from this data are provided
>
> What is the purpose of using Thrift "encoding" if it turns out to be a
> simple wrapper for existing binary data?
>
> Do you mean the goal is to have "get/set" functions to fetch data out of
> bytea field?
I mean Charles is free to choose the interface for the extension he
believes is right. There would be no much learning left in the project
if all design decisions were made beforehand.
Personally I would probably just write a Thrift<->JSONB converter. But
there are pros and cons of this approach. For instance, CPU and memory
overhead for creating and storing temporary JSONB object is an obvious
drawback. On the other hand there are time limits for this project and
thus it makes sense to implement a feature as fast and as simple as
possible, and optimize it later (if necessary).
Maybe Charles likes to optimize everything. In this case he may choose
to implement all the getters and setters from scratch. This doesn't
exclude possibility of implementing the Thrift<->JSONB converter later.
Should Thrift objects be represented in the DBMS as a special Thrift
type, or as raw bytea? Personally I don't care. Once again, there are
pros and cons. It's good to have a bit of additional type safety. On the
other hand, it's not convenient to cast Thrift<->bytea all the time, and
if we add implicit casting there will be little type safety left. In
pg_protobuf extension I choose to store Protobuf as bytea, but if
Charles prefer to introduce a separate type that's fine by me.
--
Best regards,
Aleksander Alekseev
