The problem is as follows; suppose at some time we define a view:

create view v as select somefunc(x+3, y) from ...

then at some later point either of the following happens:

• we add a new implicit cast rule for literal constants
• the return type of somefunc changes
• new overloads are added to somefunc which change the resolution

Then any uses of the view will discover a new type for the columns, effectively changing the semantics of the view. In some cases it could even break (e.g. if the overload resolution for somefunc has become ambiguous)

This is because the code that re-creates the query plan from the view descriptor infers the types using the text of the original view query using the new typing rules.

There are two parts for a full solution to this, but the first will go a long way to make views future-proof:

1. give the column types stored in the view descriptor as "demanded types" when instantiating the view plan. This will bias type checking strongly in favor of preserving the previous types and catch most problematic cases.
2. annotate the syntax tree preserved in the view descriptor with the types of every expression node and the specific builtin overload used for each function call, then skip type checking entirely when instantiating the query plan from the view descriptor.

Jira issue: CRDB-6128