There is some discussion about whether or not namespace should have a CREATE permission. This is stemming from just having name space permissions BE tablepermissions, and having their functionality extend to the namespace if approrpriate. That is, ALTER_TABLE can also be used to alter a namespace, drop_table can be used to drop the namespace, etc. However, there is no create in table and there's some discussion around that -
<vines> Basically, I don't think we need NamespacePermissions <ctubbsii> Well, there's ALTER_NAMESPACE, CREATE_TABLE, and DROP_TABLE that seem to be useful. <ctubbsii> ALTER_NAMESPACE I suppose isn't needed. <ctubbsii> But, CREATE_TABLE and DROP_TABLE are still kind of useful, if they allow only within that namespace. <vines> TablePermission already has DROP_TABLE <vines> And ALTER could be applied for altering a namespace <vines> CREATE's the only iffy one <vines> Simply because I question if table creation, regardless of namespace, is something we want to have for people who don't have hte system permission <vines> Because restricting that permission is to prevent table's from being created, period. Not creating a table with a specific name <ctubbsii> Well, one of the goals was to be able to give full access within a namespace without the system permission. <ctubbsii> We kind of need create for that... but you could add it to TablePerms.... and it just has that special meaning. <ctubbsii> (where it would only get set on namespaces, but not tables... where it would be meaningless). <ctubbsii> If you want to drop it, too, that's fine with me. Either solution (move create to tableperms, or drop it) would work for me, until I get a chance to implement the pluggable operations-based security policy I described on RB (and I think I made a ticket, too). What is the communities thoughts?
