SQL: Fix metadata handling in to_semver_no_prerelease() function

[Turbo87]

Resolves #3882

This PR is basically reviving #3886, since we now have a generated and stored semver_no_prerelease column in the versions table, which should fix the performance concerns that led to #3886 being initially rejected.

[Turbo87]

@paolobarbolini since @LawnGnome is on vacation and you've proven that you know a lot about Postgres, any chance you could take a look at this? :)

I'm most concerned about two things:

• performance impact on the reverse dependencies query, which I assume should be zero since we have the stored column now
• impact of running the create or replace function migration. it looks like drop + create is fast, but requires us to add the generated column again afterwards, which is slow. create or replace function is also fast but appears to keep the generated column, though potentially with old values.

[0xPoe]

Thanks!

[0xPoe]

Looks good to me. I forgot this is called to_semver_no_prerelease, so I deleted my previous review comments:(

Tested locally and it worked well.

[LawnGnome]

Makes sense to me, and the tests cover the two variations that are important (dash before plus, and vice versa). 👍

[paolobarbolini]

@paolobarbolini since @LawnGnome is on vacation and you've proven that you know a lot about Postgres, any chance you could take a look at this? :)

I'm most concerned about two things:

* performance impact on the reverse dependencies query, which I assume should be zero since we have the stored column now

* impact of running the `create or replace function` migration. it looks like `drop` + `create` is fast, but requires us to add the generated column again afterwards, which is slow. `create or replace function` is also fast but appears to keep the generated column, though potentially with old values.

I missed the notification 😅.

• No impact
• You should be able to replace the function. The GENERATED column won't be updated though. What you can do is write an UPDATE which assigns the raw version string to itself in order to force the GENERATED column to refresh. Should be even faster if you can filter it to only the rows which may actually need to be regenerated, although at your size it should be possible to YOLO it and just refresh the entire table and VACUUM.