sql: Restrict renames of objects that views depend on

[a-robinson]

This change is

[a-robinson]

Also fix creation of back-references to only include columns actually used by the view query.

@dt

[petermattis]

Is this the behavior other SQL engines provide? An alternative would be to propagate the rename through to the VIEW.

[a-robinson]

That'd certainly be preferable behavior, but we've basically punted on query rewriting until we can have a proper semantic encoding of the view's query rather than the current text-based one - #9045 (comment)

Unless you're suggesting that perhaps this particular case of rewriting is simple enough to handle?

[petermattis]

No, I wasn't suggesting the rewriting was easy, just wondering what the long-term goal is here. This is fine in the short-term.

One thought about how to avoid the VIEW query rewriting is that we can extend our SQL syntax in order to allow referring to tables/columns/indexes by ID. Then we'd do the name resolution once when the VIEW is created. Easy to describe this, but it would likely be a whole bunch of work to actually accomplish.

[a-robinson]

Friendly ping :)

Also, I've added a commit here to improve the test coverage for dropping indexes that a view depends on and the error messages for view-related drop errors. It's fairly independent logically, but I wanted to reuse some of the error-generating code that I added for renames to add detail to the error messages that I think improves them. Feel free to disagree on that though, perhaps the extra verbosity isn't useful?

[dt]

though we could drop TODOs in to do the query rewrite, or even use the unimplemented error message that includes the issue to help clue in users who might expect it to Just Work.

---

Reviewed 1 of 1 files at r1.
Review status: 1 of 13 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

---

Comments from Reviewable

[a-robinson]

Good point, added a TODO pointing to #10083. I didn't update the error message because I'm not sure of a way to phrase it that isn't pretty unwieldy, but do you think I should?