At the end of pg/EF0001_PopulateOIDCDb there are commands to insert the migration data into __Efmigrationshistory that use a nested SELECT … FROM … WHERE NOT to assign the values. This works if the table contains data, but if there are no rows to start with, the values are not selected, producing an empty result and empty insert.
= Alternatives
INSERT INTO … VALUES ... ON CONFLICTSELECT … WHERE NOT (without FROM clause)
I believe the intention here was to prevent the script erroring if the migration rows already exist, although this shouldn’t be possible as it is already inside an IF NOT EXISTS block. As such, it may be possible to drop the conditional stage and use a simple INSERT INTO … VALUES statement.
I am happy to create a PR with these changes to the existing file, so future migrations work as expected if there’s any guidance on the preferred method/combining inserts, unless there is a compelling reason not to update the existing file I’m unaware of.
Tested with Postgres 16 + 17
At the end of pg/EF0001_PopulateOIDCDb there are commands to insert the migration data into
__Efmigrationshistorythat use a nestedSELECT … FROM … WHERE NOTto assign the values. This works if the table contains data, but if there are no rows to start with, the values are not selected, producing an empty result and empty insert.= Alternatives
INSERT INTO … VALUES ... ON CONFLICTSELECT … WHERE NOT(withoutFROMclause)I believe the intention here was to prevent the script erroring if the migration rows already exist, although this shouldn’t be possible as it is already inside an
IF NOT EXISTSblock. As such, it may be possible to drop the conditional stage and use a simpleINSERT INTO … VALUESstatement.I am happy to create a PR with these changes to the existing file, so future migrations work as expected if there’s any guidance on the preferred method/combining inserts, unless there is a compelling reason not to update the existing file I’m unaware of.
Tested with Postgres 16 + 17