A model view still cannot name functions the connection's fun libraries provide (#62 closed, but its test asserts the opposite)

[wasabii]

#62 was closed on 2026-09-20 with:

Fixed. A model view is analyzed under the connection's own configuration, so fun, conformance and caseSensitive reach the validator that reads it.

That is not what the code or the test does. CalciteViewTests.Model_view_is_analyzed_under_calcites_default_config asserts the opposite — a model view calling NVL over a connection opened with fun=standard,oracle throws No match found — and its remarks explain why: ViewTableMacro.apply analyzes the view through MaterializedViewTable.MATERIALIZATION_CONNECTION, a static jdbc:calcite: connection with the default configuration. The divergence that would have changed this was reverted in 852edf5 ("Revert the view-analysis divergence; Calcite behaves the same way").

So as of Apache.Calcite.Data 2.0.1-pre.267, a model view still cannot name any function the connection's fun libraries provide.

Why it matters

The Cosmos adapter pushes a comparison or an ordering over a stored ISO-8601 instant only when the instant is read with PARSE_DATETIME (BigQuery library) — CosmosFactRewriter.TextAccessorOf recognises the PARSE_ family and a plain CAST, and a plain CAST cannot read …T…Z (Invalid DATE value). A federation that presents Cosmos containers through model views therefore has no way to write an instant column that pushes: the one spelling the adapter licenses is one a view cannot contain.

CAST(… AS TIMESTAMP FORMAT '…') is not a workaround. It is standard and validates inside a view, but every fraction token measured (FF3, FF, FF6, MS) drops the fraction: '2026-05-01T14:12:19.459Z' reads back as 14:12:19.000. (The adapter does not recognise it either.)

Repro

var cs = new CalciteConnectionStringBuilder
{
    Model =
        "inline:{\"version\":\"1.0\",\"defaultSchema\":\"adhoc\",\"schemas\":[{\"name\":\"adhoc\"," +
        "\"tables\":[{\"name\":\"V\",\"type\":\"view\"," +
        "\"sql\":\"SELECT PARSE_DATETIME('%Y-%m-%d''T''%H:%M:%S.%E3S''Z''', '2026-05-01T14:12:19.459Z') AS Y\"}]}]}",
    Schema = "adhoc",
    Fun = "all",
};
using var c = new CalciteConnection(cs.ConnectionString);
c.Open();
using var cmd = c.CreateCommand();

// works: the connection has the BigQuery library
cmd.CommandText = "SELECT PARSE_DATETIME('%Y-%m-%d''T''%H:%M:%S.%E3S''Z''', '2026-05-01T14:12:19.459Z')";
using (var r = cmd.ExecuteReader()) { r.Read(); } // 2026-05-01 14:12:19.459

// fails: No match found for function signature PARSE_DATETIME(<CHARACTER>, <CHARACTER>)
cmd.CommandText = "SELECT Y FROM V";
using (var r = cmd.ExecuteReader()) { r.Read(); }

fun=all, fun=all,bigquery and fun=standard,bigquery all behave the same.

Declaring a schema function named PARSE_DATETIME gets the view past analysis, but the same name then resolves to that function when the view is expanded, so the plan carries it rather than the library operator.

Ask

Analyze a model view under the configuration of the connection whose model declared it — at least fun — so that a view can contain the expressions an adapter pushes. If staying with Calcite's behaviour is the deliberate position, it would help to say so on #62 and reopen or re-scope it, since the closing comment currently says the opposite.