Re: GSoC 2018: thrift encoding format

Greetings,

* Aleksander Alekseev (a(dot)alekseev(at)postgrespro(dot)ru) wrote:
> >> 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.

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.

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

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

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.

Thanks!

Stephen