Regarding #1, sets and bags are both widely used in practice so restricting to just one or the other seems unnecessarily limiting. If there are benefits to res

Regarding #1, sets and bags are both widely used in practice so restricting to just one or the other seems unnecessarily limiting. If there are benefits to restricting oneself to sets then one can restrict oneself to sets and get those benefits. The only possible drawback I can see is making the API surface area too large and unwieldy. But I don't think that applies here. Regarding #2, that's interesting, they've done the same sort of "if you have one you have the other" analysis that I did for sets vs. bags, and concluded that you only need the more general one. I have to say I don't follow their rationale. It still seems to me that relations should have a single field. If you want to simulate "multiple fields" then make the "single field" a tuple. That's what Opaleye does and it works very naturally. As an aside, thanks for your work on Postgres. It's a great system!