> and produce correct results This doesn't interfere with that. > relying only on the structure and content of tables Constraints are part of the table schem

> and produce correct results This doesn't interfere with that. > relying only on the structure and content of tables Constraints are part of the table schema, not index schema. > his proposal would break that constraint, by elevating the _name_ of a foreign key constraint to an identifier usable in a DQL statement (as distinct from DDL statements where such names can already appear). That's not allowed. Not allowed says who? The standard? I doubt it, and anyways, it can be changed. "That's not allowed" is not a good argument. A better argument is that this is the first time a constraint can change the meaning of a query -- that is a good argument, but it would be better if the constraint could change existing queries, which it does not do. Because this would only affect queries that refer to the constraint, this seems quite allowable to me. > More importantly, it's _not a good idea_, because that semantic separation between data on one side, and the machinery of acceleration and validation on the other side, ... This is not about optimization, ergo this argument is out. I'm not sure I want this particular extension, but I don't buy your arguments against it.