Hello Stephen, > Perhaps the design decisions aren't all made beforehand, but they also > shouldn't be made in a vacuum- there should be discussions on -hackers > about what the right decision is for a given aspect and that's what > should be worked towards.
+1, agree. > > 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). > > Just having such a convertor would reduce the usefulness of this > extension dramatically, wouldn't it? Considering the justification for > the extension used on the GSoC project page, it certainly strikes me as > losing most of the value if we just convert to JSONB. > > > 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. > > Having a way to cast between the two is entirely reasonable, imv, but > that's very different from having the data only able to be stored as > JSONB.. Good point. > I understand that you're open to having it as a new data type or as a > bytea, but I don't agree. This should be a new data type, just as json > is a distinct data type and so is jsonb. Could you please explain in a little more detail why you believe so? Also I wonder whether in your opinion the extension should provide implicit casts from/to bytea as well. -- Best regards, Aleksander Alekseev
signature.asc
Description: PGP signature
