Re: pgsql: Add a non-strict version of jsonb_set - Mailing list pgsql-committers

> On Jan 19, 2020, at 12:20 PM, David Fetter <david@fetter.org> wrote:
>
> On Sun, Jan 19, 2020 at 12:46:19PM -0500, Tom Lane wrote:
>> David Fetter <david@fetter.org> writes:
>>> On Fri, Jan 17, 2020 at 06:41:02PM -0500, Tom Lane wrote:
>>>> I'd be okay with a hook that there was a way to override ("yes,
>>>> I know what I'm doing, this doesn't require a catversion change").
>>>> But there's no way to do that is there?
>>
>>> I'm pretty sure there is. The program called by the commit hook can
>>> prompt the user for input.
>>
>> ... um, but the commit hook in question would run on the repo server.
>> Is there really something in the git protocol that would allow sending
>> this sort of interaction back to the person running "git push"?
>
> According to the folks I consulted, that would require special magic
> on the client side.
>
> How about something that sent an email or otherwise signaled the
> person pushing that this situation obtained? It's not ideal, but it's
> centralized, so harder to get inconsistent.
>
>> 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.
>
> Distributing the problem by asking people to have those hooks on their
> private repo seems like a suboptimal move. Change dev boxes, and watch
> your carefully structured safeguards vanish.

I disagree.  If you have a committed directory containing hook scripts, and
a script in src/tools that can instantiate the hooks of your choosing in your
development repository, then client-side hooks can be shared between
developers without forcing any developer to use any particular hook.  I
have been annoyed in the past that .git/hooks is not itself under version
control, so shared hook scripts need to go elsewhere for versioning, and be
optionally copied to .git/hooks by some new tool, say src/tools/make_hooks.

Client side hooks of this kind could be useful for developers without
community commit privileges, since local repository commits could also be
rejected, perhaps with an “are you sure” type override option, and more
than a catversion checking hook would be possible.

I have wanted a hook to check code indentation [1], and not all developers
agreed it would be useful enough to be worth the pain of rejecting commits.
If it were a client side hook, and had “are you sure” logic rather than
rejecting the commit unconditionally, it might be more popular.  Either way,
each developer could opt-in or opt-out as they like when running make_hooks.

Does anybody object to this idea in principle?  If not, I can put something
like this together from a similar script I already have lying around.


[1] https://www.postgresql.org/message-id/7825.1511902037%40sss.pgh.pa.us

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company