db.constraint assumes a unique index implies a matching constraint

[scottcollabai]

Hi there -- huge fan of Zapatos!

Issue: db.constraint takes in UniqueIndexForTable as its parameter. However, if one were to enforce column value uniqueness using CREATE UNIQUE INDEX directly (instead of ALTER TABLE ... ADD CONSTRAINT), you wind up with a 'valid' value for db.constraint that results in a runtime error from Postgres if you actually try to use it.

Per the PG docs I don't think it's preferred to use CREATE UNIQUE INDEX in this way, but in our case, we use Prisma Migrate to generate our schema migration scripts. Prisma Migrate so happens to only generate a CREATE UNIQUE INDEX statement if you mark a column as @unique in the Prisma schema, so it's actually quite easy for us to hit this issue in practice. That's likely an issue on their end too...

[jawj]

So it sounds like Zapatos wrongly identifies some indexes as valid for use in an upsert that aren't actually? I haven't got a lot of time to work on this right now. Do you happen to know how we'd need to change the relevant query that's run at generation time?