Hi!
For a couple of reasons, the sql in sql/dbcatalog.sql is causing us problems:
- pg_temp doesn't work on AWS Aurora
- Our Aurora database is unfortunately still on postgress 11, and the sql fails with an error there
It looks like we could nearly work around those issues by passing custom user_sql_files into connect_to_db(). But, we still have the problem of dbcatalog.sql erroring out. It seems that the only way to prevent that is to override connect_to_db() and connection_factory, removing the lines that run the sql from the latter class. Which seems quite messy.
Maybe it'd be neater if user_sql_files ran instead of dbcatalog.sql, not before it? If somebody just wants the default + their custom sql, it's easy enough to include tipg.database.DB_CATALOG_FILE in the list. It'd also make it possible to choose the order the files run in. Or to skip inspecting the db and create the collection catalog in some other way.
What do you think? If I did a PR what'd be the chances it'd be accepted?
Hi!
For a couple of reasons, the sql in
sql/dbcatalog.sqlis causing us problems:It looks like we could nearly work around those issues by passing custom
user_sql_filesintoconnect_to_db(). But, we still have the problem ofdbcatalog.sqlerroring out. It seems that the only way to prevent that is to overrideconnect_to_db()andconnection_factory, removing the lines that run the sql from the latter class. Which seems quite messy.Maybe it'd be neater if
user_sql_filesran instead ofdbcatalog.sql, not before it? If somebody just wants the default + their custom sql, it's easy enough to includetipg.database.DB_CATALOG_FILEin the list. It'd also make it possible to choose the order the files run in. Or to skip inspecting the db and create the collection catalog in some other way.What do you think? If I did a PR what'd be the chances it'd be accepted?