examine function-derived attributes

[agentm]

I wonder if SQL-style views could be superseded by function-based attributes. I imagine the function signature would look something like this:

f :: RelationTuple -> Atom

where the tuple is the current tuple context to be used for deriving new attributes. This could also be used with grouping for

This would allow derived columns to be conveniently attached to relations without incurring a storage cost.

I need to investigate if such a feature would break any of the laws involving data independence or constraints.

[YuMingLiao]

it seems to me that function-derived attributes can be safely referred to in a relational expression.

However, if it is allowed in insert and upsert, it implies that the attribute can be function-derived OR user-defined and then make unexpected result. So the function-derived attribute name needs to be disallowed in insert/update/upsert and the value needs to be derived automatically when insert/update/upsert.

As to constraints, the constraints on the left (RelationTuple) seems only shrink the deriving function's input set.

And the constraint on the right (Atom) may conflict with the deriving function's output set. It needs to be reflected on the insert/update/upsert error.

[agentm]

Interesting points. Does this imply that the function-derived column should be of a different type despite generating standard values?

[YuMingLiao]

On second thought...

Tuple function is like atom function. It can be used in relational expression to extend an column.

And we want data independence.

So maybe we can define a macro like someView = s : { viewAttribute :=f #s }

It doesn't take space. It just need to be a valid expression.

Then it can be used later in something like showexpr someView.

And it's not allowed to insert/update/upsert macros by nature because it's not a relvar.

And if the column value needs to be constrained, it can be done by giving the right function.

So the column need not to be of different type. It just need to be defined in macros in order to avoid change.

When the function-derived column is defined in a relvar assignment, it implies that the tuple function is used for initialization. Values may be changed by the user. And the user doesn't care about the consistency that the tuple function brings.