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
signature.asc
Description: PGP signature
