-
-
Notifications
You must be signed in to change notification settings - Fork 51
Description
Doltgresql version 0.55.5, macOS
Issue with Prisma integration. With dolt_show_system_tables set to 1, any query to information_schema.columns will fail. You'll get an error that looks something like this, with a different table in the error message each time:
postgres=> select(dolt_show_system_tables);
(dolt_show_system_tables)
---------------------------
1
(1 row)
postgres=> select * from information_schema.columns;
ERROR: table not found: commits (errno 1146) (sqlstate HY000)
postgres=> select * from information_schema.columns;
ERROR: table not found: remote_branches (errno 1146) (sqlstate HY000)
I've spent some time looking into this and the problem points seem to be as follows, but I'm a little lost to what the solution is:
In AllColumns in GMS here. This for loop will iterate over entries in the databases slice that each look something like the following:
Database one: Catalog name "postgres" with schema name "dolt"
Database two: Catalog name "postgres" with schema name "public".
Then in database.go here in Dolt, the results will cause an issue. this function produces a list of system tables that contains 2 copies of each, one with and one without the dolt (dolt_ namespace). So for instance there will be a dolt_commits and a commits, as well as a dolt_remote_branches and a remote_branches.
This then causes an issue when combined with the databases I listed above. When checking if each table does in fact exist, it gets to this check in Dolt.
The check for whether something is a system table returns true when either the name begins with dolt_ or if the pattern [schema_name]_[table_name] is a valid system table.
Considering the two databases I listed above, it works in the first case but not in the second. In the first case, if you have a table like commits, it will see that it does not begin with dolt_, but can see that [schema_name]_[table_name] matches the system table dolt_commits.
However, in the second database, neither pattern will match, since [schema_name]_[table_name] will be public_commits, which is not a existing system table. This then produces a table does not exist error after which the query fails.