Do you think we'll need to reuse the pg error checks? Should we have database pkg functions like:

if database.IsUniqueConstraint(err, "column_name") {
	// ...
}

Just spitballing ideas. I think you also need this check on the post workspace route too right?

@Emyrk I like that suggestion. What do you think about also pulling out the constraint names from dump.sql and creating constants for them in a generated file?

Edit: Example in 85eb0cf.

@Emyrk I like that suggestion. What do you think about also pulling out the constraint names from dump.sql and creating constants for them in a generated file?

Edit: Example in 85eb0cf.

I've been wondering if we should generate some Golang code like we do typescript code from our database schema. It might be a bit preemptive to go that far now, unless you think this error checking will be useful outside of just workspace and user names.

If we do generate though, I'd like to expand our enum generation in Go. Currently sqlc generates Enums to models.go. I'd like to expand that to copy the enums to codersdk somehow and add some functions for validating enums. Right now you can see we handle some enum validation manually

@Emyrk

I've been wondering if we should generate some Golang code like we do typescript code from our database schema. It might be a bit preemptive to go that far now, unless you think this error checking will be useful outside of just workspace and user names.

My thinking is that the value is in ensuring our code is in sync with the schema. For instance, the unique index we're relying on here could be recreated with a different name at some point, and in that case the code would silently no longer catch the case. By generating the enums we ensure that the project fails to build unless names are in sync.

Ultimately it'd be great if we strive for having all relevant parts generated into Go code (to ensure synchronization), but I don't think it needs to be an all or nothing approach. I.e. it'd be fine to generate a subset now, and more as the need arises.

It didn't look like sqlc supports generation of unique constraint enums, so I was thinking of doing some manual lifting in this case (based on dump.sql).

But this is annoying to maintain in json tags, it would be great to handle this with some autogen "validate" function imo.

(Not relevant for this PR, but) That looks annoying indeed. I think one of the libraries I mentioned in #3390 (comment) would support the custom Validate() error function, which sounds like what we'd want.

While #3386 is not fixed yet, I opted to add a large disclaimer to the rename command:

❯ ./coder rename test byebye
> WARNING: A rename can result in loss of home volume if the template references the workspace name. Continue? (yes/no) no

I think this should be sufficient for us to merge this functionality.