3 ms·

> A stored procedure that takes a fathers(text, text) row, shouldn't necessarily be able to accept a mothers(text, text) row! Of course, in the real world, you

• derefr 5y ago
  It wasn't the best example. Here's a better one: CREATE TABLE siblings(personA text, personB text); CREATE TABLE owners_pets(owner text, pet text); Under structural identity, both of these would be just considered to be (text, text) tuples. Even in the grittiest of real-worlds, I think you'd agree that there's no place where you'd want something that explicitly says it operates on siblings rows, to implicitly accept and operate upon an owners_pets row instead. (They aren't even the same shape of relationship. One's symmetric, while the other's directed!) And, to be clear, if you just wanted function on a generic (text, text) tuple-type, you could declare such a type, and explicitly cast your other types to it to use such a function on them. So no, that's not a good reason. ----- Mind you, in some places in SQL, structural identity is used. Mostly when you explicitly "ask for it" to happen, by making use of some destructuring or 'restructuring' operator. Even when it makes no sense! -- ridiculous, but legal SELECT * from siblings UNION SELECT * FROM owners_pets This is mostly because it'd be really inconvenient for the "temporary relation types of projected result-sets" case if UNION didn't use structural identity. It'd be the same sort of "now forced to give all your temporaries names" issue that afflicts Java's closures under checked exceptions, and Rust's lifetime annotations under lexical-capturing garbage-collected self-terminating actors.