You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could probably be done without too much effort by creating a hidden column that is given a uuid. I'm not sure why we'd want this in practice, though part of the sqllogictest suite uses tables with primary keys which might be reason enough.
The text was updated successfully, but these errors were encountered:
I've downplayed the need for tables without a primary key in the past, but now I think they're worth doing. I've looked at two more SQL test suites that we may want to consider (In python: the dbapi-compliance package and sqlalchemy's dialect test suite), and both use tables without primary keys.
As an alternative to introducing the concept of hidden columns, we might be able to get away with making all of the columns the primary key. This would make the table difficult to alter since you can't change a primary key, but it would be enough for tests.
Making the primary key all of the columns would be straightforward, though I wonder if any tests rely on being able to insert duplicate rows. A hidden primary key column would not be difficult, especially now that we have default values and unique id generation.
Having explored this a little further, there are some tests in the sqlalchemy suite that do rely on being able to insert duplicate rows, so a hidden primary key column would be the more compatible solution.
This could probably be done without too much effort by creating a hidden column that is given a uuid. I'm not sure why we'd want this in practice, though part of the sqllogictest suite uses tables with primary keys which might be reason enough.
The text was updated successfully, but these errors were encountered: