Greg Weber

Great! More detail is needed.

I added #46 for implementation details. This PR will remain to provide a motivation and comparison with other possible implementations: I think that information is distracting when one would like...

> Key spaces sound like a solution to the problem [tikv/tikv#3922](https://github.com/tikv/tikv/issues/3922). A key space would be designated as transactional or non-transactional when it is created?

> the most important thing I think is the resource isolation Yes. Key spaces registered for applications provide a crucial piece of meta information that can be used to help...

I added an [auth proposal](https://github.com/tikv/rfcs/pull/40). This builds on top of key spaces and hopefully helps to motivate them a bit more, particularly in demonstrating why they can't be implemented client-side....

@huachaohuang we already have some ability to have different settings for different tables. So I am not sure if keyspaces are needed for that. Currently I am suggesting that TiDB...

I see, you want prefix abstraction. The keyspace abstraction in this proposal guarantees no conflicts when importing data by altering the prefix during import, but cannot guarantee no conflicts when...

I think the cluster id could potentially be useful to associate with the default namespace. However, if we attempt to use the cluster id for this we will change the...

I am considering a design where TiKV does not have any knowledge of keyspaces. Keyspace is an organizational concept that exists only in PD where clients can register their keyspace...

This RFC is changed now so that TiKV has no knowledge of key spaces. I created a new RFC for TiKV to assist with sending prefixes that can be used...