Add `VOLATILE` keyword

[vpetrovykh]

Currently we have no way of distinguishing volatile from stable functions. This is problematic both in terms of optimizations that the backend can make as well as human reasoning about queries.

The archetypal example is random:

SELECT Foo {
    bar,
    r := random()
};

Is the above any different from the following in terms of data it gets and why?

SELECT (
    bar := Foo.bar,
    r := random()
);

What happens when a user-defined function is used in place of random?

Another pair of examples that seem very similar but should construct different sets:

FOR x IN {1, 2, 3}
UNION (x, random());

SELECT ({1, 2, 3}, random());

[1st1]

We'll add a volatility enum property to Function schema objects with the following values: volatile, immutable, stable.

[vpetrovykh]

We can add a volatility attribute (much like session_only attribute #406). The attribute would be using an enum as its value:

CREATE SCALAR TYPE volatility_t
    EXTENDING enum<'IMMUTABLE', 'STABLE', 'VOLATILE'>;

The enum values simply reflect the PostgreSQL volatility options.

The order of the enum values is chosen so that it goes from lower to higher volatility. This would enable introspection queries like:

SELECT schema::Function {
    name
}
FILTER .volatility <= <volatility_t>'STABLE';

The default volatility would be VOLATILE.

Of course, functions can only use other functions of same or lower volatility in their EdgeQL bodies.

[1st1]

The order of the enum values is chosen so that it goes from lower to higher volatility.

+1

[vpetrovykh]

Due to current implementation limitations the schema should continue using the one_of constraints instead of an enum. The reflection between Python and the schema.edgeql does not currently work with enums. In the future we may replace these schema scalars with proper enums.

By pure coincidence, 'IMMUTABLE', 'STABLE' and 'VOLATILE' are already in ascending lexicographical order, so comparisons between them would produce the same result as comparing proper enums.

[1st1]

@vpetrovykh Didn't we implement this one?

[vpetrovykh]

It appears to have been implemented in c24bfe191ae85fdb7df44b95d1bb33ee212225c1