From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: Add a non-strict version of jsonb_set |
Date: | 2020-01-20 00:18:57 |
Message-ID: | 25888.1579479537@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> writes:
> On Mon, Jan 20, 2020 at 4:16 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think you are right that individual committers could set up such hooks
>> in their own private repos. But that's not what was being suggested,
>> or so I thought.
> I was really thinking of a client side hook. The reason I started the
> discussion is so I could institutionalize the knowledge, e.g. by
> adding something to the wiki.
Ah, that makes sense. Although Mark's idea of including a library
of possible hooks somewhere under src/tools/ seems even better.
> I was also thinking of something that would give a warning rather than
> reject the commit. Then the committer could ignore it or not as they
> choose. Something like that might also be valuable on the server
> side, since it would mean all committers would get the warning when
> appropriate, but it might not be worth the trouble.
Another point is that a server-side hook is really too late: you'd
rather get the notice before you "git push", not after.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-01-20 02:33:34 | pgsql: Allow vacuum command to process indexes in parallel. |
Previous Message | Tom Lane | 2020-01-20 00:15:23 | pgsql: Fix out-of-memory handling in ecpglib. |