sql: Support for selecting from views

[a-robinson]

In the process, open the floodgates to grabbing leases on views.
I believe I've handled all the callers that get a table lease, but let
me know if you think I might have missed something!

Only look at the last commit in this PR - everything else is just a copy of #9212, which I'll rebase on top of once it gets in.

@dt @paperstreet

---

This change is

[a-robinson]

#2971

[a-robinson]

Hm, I've locally rebased this on top of #9212, but in the process broke the test case that joins two views together. Investigating...

[a-robinson]

So the issue got triggered by something in #9327. If I run the view logic tests against what's currently up in this PR, it works, but if I cherry-pick #9327 on top of it, the join in the logic test starts panicking. It even affects pre-existing tables/views that were created on disk before #9327. Taking a closer look at the contents of #9327 now.

[a-robinson]

Looks like the change to AllocateIDs that ensures a primary key exists is the culprit, somehow. I'll rework it to make more sense for views.

[dt]

huh, sorry about that.

maybe we should a) unify some view and virtual table handling (i.e. #9361) then b) opt non-persisted tables out of ensuring they have PK/Families?

[a-robinson]

I haven't checked out virtual tables enough to know what unification would involve, but I can try taking a look if you'd like. I assume this is the same conversation as #9361?

[dt]

yeah, I think it's fine to check IsView to opt views out of automatic PKs and Family allocations, plus the places in Validate which will need to check that, and then maybe make IsView true for virtual tables too (which is kinda the direction I was thinking on #9361).

[a-robinson]

Alright, I've opted views out of PKs, indexes, and families, and shuffled the validation code around a little bit to accommodate. I'm happy to do more invasive surgery if you think it'd be better long term.

[dt]

LGTM

I think I'd have a slight preference to keeping AllocateIDs() callable on any tabledesc and having it Do The Right Thing internally, but I don't feel that strongly.

[danhhz]

I do think we need more invasive surgery, this is all getting a little hard to follow. But we certainly shouldn't shave that particular yak in this commit.

I haven't looked deeply at this commit, but would it be possible to move to a structure where AllocateIDs does whatever work is shared between physical tables, views, and information_shcema and once calls AllocatePhysicalTableIDs for regular tables? Or is the logic too intermingled for something like that?

(edit)
If not, then an LGTM from david is good enough for me.

[a-robinson]

How about this version? It merges a tiny bit more of the logic for views and virtual tables and makes it safe to call AllocateIDs and ValidateTable on all table descriptors. It's stricter about not allocating even an ID to the nameless primary index on virtual tables, so I had to tweak the hard-coded table descriptors for the information_schema.

[a-robinson]

All the relevant changes around that are in the first commit, in case it's not clear

[dt]

👍 LGTM