fix metadata views, incorrect query

[beltran]

Fixes #1435

[jorgebay]

I didn't have time to check it earlier, I'll review this on Monday.

[mpenick]

What do you think about having a pointer to the base table? possibly instead of ID and name?

BaseTable *TableMetadata

One drawback: Views would have be executed in serial order after table metadata.

[beltran]

I think it's a good idea, but it would only replace BaseTableName right? Because TableMetadata doesn't have the BaseTableId.

[jorgebay]

Should we be concerned about breaking existing usage for ViewMetadata (udts)?

We have the option of leaving ViewMetadata as is and introduce a MaterializedViewMetadata for system_schema.views, wdyt?

[beltran]

Hmm, I may not fully understand what you mean, the problem I think it's that a bug that caused a change in the API was introduced. So you are suggesting adding below here a new line MaterializedViews MaterializedViewMetadata and leaving the data in Views as it is? Couldn't users get confused when they see both fields?

[jorgebay]

Yeah, I understand that it may cause confusion to new users (we can document the behaviour. Introducing a new map+struct and leave the existing functionality as it is will avoid breaking usages of views as udts.

[beltran]

@jorgebay thank you for the feedback! I think this is ready for another looks. There's a failing test in one of the runs, but seems unrelated:

--- FAIL: TestPolicyConnPoolSSL (0.12s)
    conn_test.go:1191: write tcp 127.0.0.1:34668->127.0.0.1:34356: use of closed network connection

[jorgebay]

Looks great!