"Primary key" constraint still generates an id column

[o1lo01ol1o]

Perhaps related to #68, adding a version of the following constraint from the examples to my schema still produces an id column with a primary key constraint when I export via JDBC. I would expect that the primary key should be set on the composite attribute and there would be no id column, but maybe this implementation is by design?

#####################################/
#primary key constraints

schema Sch = literal : Ty {
	entities
		E
	attributes
		att1 att2 att3 : E -> dom
}

#says (att1,att2) is a primary key
constraints PkForSch = literal : Sch {
	forall x y : E
	where x.att1 = y.att1  x.att2 = y.att3
	->
	where x.att3 = y.att3
}
instance I = chase PkForSch Sch

command go = export_jdbc_instance i  "jdbc:postgresql://localhost:5432/foo" "" 

[wisnesky]

JDBC export is definitely not smart enough to look inside PkForSch-- and for good reason; it's a tough theorem proving task to determine if for example an arbitrary constraint is equivalent to a PK. The JDBC export just exports into 'categorical normal form', where every exported row gets a new unique single column PK. to make matters worse because of SQL's nulls and 3 valued logic it's not necessarily even the case that CQL constraints that looks like PKs actually are

[o1lo01ol1o]

gotcha, thanks!

[wisnesky]

btw, we have an alternate SQL import pathway now that goes through the system catalog / INFORMATION SCHEMA views. We should chat offline sometime if you're in an environment where the exact semantics of SQL really matters.