if the base domain is sets we do get a lot of nice constraints, particularly with semantics around projections and if we want to support bags, its trivial to add a counter for the number of identical records as an additional column.
if we want to support sets in bag-land, we could imagine an extension which support 'row unique' on insertion. or we can use a 'unique results' post-filter. so there are paths, but its a lot less clear in a SQL context.
you insist that your data demands bags. I really prefer to work in sets and bagginess is always just a source of crappy errors for me. shouldn't we really support usable models for both regardless of the underlying storage?
Correct.
> you insist that your data demands bags.
No, I insist that real data needs both. You can bias the language/engine in one way or other.
The underlying problem is that once you say:
> if we want to support bags, its trivial to add a counter for the number of identical records as an additional column.
Then it means that this is second-class.
The main gripe I have, is that the relational model has this beautiful promise of "make the storage invisible" but need to have a coherent semantics about the data.
If you say "2 identical values/rows can't exist" then we adding the same problem that all the rdbms has: None implement the relational model, and none can deal with "relation on relations".
Imagine how crazy if I tell you a language can't do `[[1,2], [1, b10000]]` and to get into `b10000[:1] where ...` is necessary to switch to another paradigm.
P.D: note how "2 identical values can't exist" break when you have 2 columns, of numerical values, where the slice of both are the same value pair-wise: Are the 2 columns wrong?. And if both are called the same? same type? from different or same table? etc. "Duplicated" values are everywhere and is trivial to get there.
And if you "add a column" then it breaks the soundness of the language:
IN: [1, 1] != OUT: [1: 1, 2: 1]