ALTER TABLE equivalent

[boogerlad]

I looked around the docs and didn't see anything to change type of / add / remove / rename an attribute in a relation, but saw #307 mention

need to undefine a, make changes to the attribs and update the tuples accordingly and redefine it

Doesn't undefine destroy the tuples too? Regardless that seems like a lot of work compared to sql. I expected Int -> Integer to be lossless or Text -> Double to be doable given some sort of user defined conversion function (or be emulated by creating a new attribute and then specifying new values for all tuples, then removing the old attribute). Add / remove / rename should be even easier.

Same with undata. What if I just want to change its underlying type and keep the name, or just rename?

[agentm]

Project:M36 is a bit unusual in that it doesn't have any specific tuple store for a relvar and that it can "stack" update expressions without materializing tuple data, so there is no real correspondence between relvar creation+deletion and what happens on disk. C.J. Date calls this property of databases "data independence" and it's a powerful concept which unlocks many interesting optimizations.

In the same vein, deleting a relvar does not clear the tuples from disk and does not incur any substantial cost. It's more like a filesystem unlink() whereby only metadata is touched. While it may be valuable to have some shortcuts equivalent to alter table, it would do nothing more than redefine the table.

If we think of relvars as being typed, then it doesn't really make sense to delete them, however, as you surmised, it is possible to create a new relvar with the attributes you want, undefine the old relvar, and rename the new relvar to the old relvar's name (simulating an alter table). This is different conceptually from Haskell where types are fixed at compile time. In Project:M36, we acknowledge that the shape of data must change over time, but relvars must still be typed.

That being said, some alter table equivalent commands would definitely improve the developer ergonomics without substantial cost- they would merely be wrappers around what you can already do today.