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
