Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints
От | Nico Williams |
---|---|
Тема | Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints |
Дата | |
Msg-id | 20180711211043.GB9712@localhost обсуждение исходный текст |
Ответ на | Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Wed, Jul 11, 2018 at 03:13:30PM -0400, Alvaro Herrera wrote: > On 2018-Jun-06, Nico Williams wrote: > > I've finally gotten around to rebasing this patch and making the change > > that was requested, which was: merge the now-would-be-three deferral- > > related bool columns in various pg_catalog tables into one char column. > > > > Instead of (deferrable, initdeferred, alwaysdeferred), now there is just > > (deferral). > > Nice stuff. > > Please add #defines for the chars in pg_constraint.h instead of using > the values directly in the source. Also, catalogs.sgml has a typo in > one of the values. > > What happens if you do SET CONSTRAINTS ALL IMMEDIATE and you have one of > these constraints? I expect that it silently does not alter that > constraint, but you didn't change that manpage. Correct, that's the idea, that it should be possible to write deferred constraints/triggers which users cannot make immediate. For example, an audit extension that logs changes via FOR EACH ROW ALWAYS DEFERRED, or my PoC COMMIT TRIGGER implementation (which depends on deferred triggers). I missed that there is a page for SET CONSTRAINTS! I'll update it. > I suggest not to include psql/tab-complete changes with your main patch. > If you want to update it, split it out to its own patch. Committer can > choose to include it in one commit or not (I'm mildly inclined not to, > but I'm probably inconsistent about it), but for review IMO it's better > not to mix things -- It's way too easy to get entangled in silly details > while editing that code, and it's not critical anyway. OK, sure, though, of course, the committer could always leave that out themselves, no? To me though it seems that the change should be complete. > > Incidentally, I had to do commit-by-commit rebasing to make the rebase > > easier. I have a shell function I use for this, if anyone wants a copy > > of it -- sometimes it's much easier to do this than to do one huge jump. > > I've done this manually a few times. Please share, I'm curious. OK, attached is my latest version of that script, though this one is a bit changed from the one I used. This version tries to be faster / more efficient by first doing 1 commit, then 2, then 3, and so on, and on conflict aborts and halves N to try again. The idea is to only have to merge conflicts at each commit where conflicts arise, never resolving conflicts across more than one commit -- this makes is much easier to reason about conflicts! Note that the script is actually a shell function, and that it keeps state in shel variables. A better implementation would do the sort of thing that git(1) itself does to keep rebase state. Nico --
Вложения
В списке pgsql-hackers по дате отправления: