|From:||Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>|
|To:||Nico Williams <nico(at)cryptonector(dot)com>|
|Subject:||Re: [HACKERS] [PATCH] WIP Add ALWAYS DEFERRED option for constraints|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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.
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.
> 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.
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Fabien COELHO||2018-07-11 19:34:33||Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors|
|Previous Message||Andres Freund||2018-07-11 18:56:28||Shouldn't validateForeignKeyConstraint() reset memory context?|