Add set_constraints helper for PostgreSQL

[ccutrer]

The docs already talk about how to set up deferrable constraints, but then rely on tthe user crafting custom SQL to actually use the feature. The helpers makes it easier to handle juggling multiple specific constraints and quoting issues.

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[yahonda]

@alpaca-tc What do you think about this pull request? I'm asking this question because you have authored #46192 and #47655 .

[alpaca-tc]

@yahonda I think the #set_constraints support is a good idea. I also like the method interface was nice. 👍

As for #defer_constraints, I am not sure if it should be supported in Rails. I think it would be nice to let users extend it in their own applications.

• 1. I feel uncomfortable that #immediate_constraints, which does the opposite of #defer_constraints, does not exist.
• 2. As in the following code, depending on the kind of exception that occurs in the #defer_constraints block, the behavior is not as expected.

begin
  Post.connection.defer_constraints do
    raise 'a'
  end
rescue
  # The user expects the constraint to be back to IMMEDIATE, but it remains DEFERRABLE.
end

[ccutrer]

2. As in the following code, depending on the kind of exception that occurs in the #defer_constraints block, the behavior is not as expected.

I actually went through several iterations of what to do here, before simply leaving it very simple. In most cases, any exception will end up rolling back the transaction anyway. One of my attempts was to inspect the connection's state and see if a transaction was open, and if it wasn't avoid rolling it back. But then you have to special case Rollback, to not set the deferred state, since the transaction is going to rollback anyway, it's just a wasted command. And then realized that for most other exceptions, that's also the case. And technically just because we set constraints to deferred, doesn't mean it was initially immediate, so setting it "back" to immediate may be wrong. It all seems rather complicated. In light of all that, I think it would probably be best to get rid of the defer_constraints helper, and only add set_constraints. Thoughts?

[zzak]

Sorry I left some knit-picks on the ChangeLog, that are not super important. Upon thinking about this though, I think I like the idea of just adding set_constraints here, and to think about defer_constraints more after.

[alpaca-tc]

I think I like the idea of just adding set_constraints here, and to think about defer_constraints more after.

agree 👍

[ccutrer]

rebased, defer_constraints helper removed, and tests and changelog updated appropriately