[]int8, []int16, []int32, []int64, []uint8 datatypes

[krolaw]

In the data I'm playing with, it's useful to contain groups of non-indexable integers, like storing one graph dataset per record. To handle this situation, I intend to use blobs and then pull out each int with encoding/binary.Varint().

Then I wondered how cool would it be if ql extended the idea of the already supported []uint8 (blobs) and added support for arrays of all data types.

Thoughts? Abuse?

Thanks.

[cznic]

I have to think about this idea, but I have little chance to have some free time this week. Please be patient ;-)

[cznic]

The proposal probably enables some new and nice things, I think. Making it a bit more orthogonal (support all QL types) and extending the {index,slice} operation to support it (ATM works only on strings) is feasible, I guess. Also, it's probably a lot of work...

However, I'm not sure if making QL such an exotic SQL dialect is a good idea or not. You might want to try to convince me by some great usage example(s) ;-)

#MaybeSomeTime

[krolaw]

I guess it depends where you want to take QL. Having a native sql engine is handy as it eliminates the CGO cross compilation complexities of SQLite. I was hoping that QL would also be the Go native SQL engine for Go data, but I can appreciate that this may not be the intended direction.

[cznic]

Thanks for sharing your thoughts, I appreciate it. I'm, however, still on the fence about this.

[gernest]

While the structures looks useful. They are composite structure, It will be totally a waste of resource to store the building materials and the resulting house.

What I am saying, you can easily obtain []ints by collecting the ints from your store. But If we start storing []int reasoning about relationship between your data models will be hard .