Is hashing schema information for client when generating SQL queries more secure?

I'm planning to implement a web system wherein APIs and presentation for CRUD in data tables are automatically generated, like that in phpMyAdmin. How I plan to implement this is to construct SQL statements based on requests from the client.

1. Client receives metadata (table, column) information from server.


2. User interacts, does something, say update a column on a row.


3. Client sends request, including an identifier for the table, an identifier for the row, identifier of the column and the new column data.


4. Server builds query and executes stuff.

Now what I'm interested in are the highlighted words in #3. Just using plain identifiers (the name themselves) would enable savvy users to easily modify requests to their will (e.g. directing request to another table/column). Another important thing I consider is having a read-only presentation, which still should include table metadata for things like sorting, filtering, etc. I'm quite eerie of exposing such metadata when unencrypted communication is used.

Provided that sufficient security (transport encryption (except for some cases), input sanitation, privilege checks) are in place, my question is:

• Will hashing (obscuring, maybe in a different fashion) the table metadata (table name and/or column names) provide any additional security? Or will input sanitation (making sure the table name passed is really a table, same for columns) and privilege checks suffice?

---

I realized that for most of the case (that is, except for the read-only scenario stated above) the user is already inside the airtight hatchway, but would hashing still improve security?