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

From Tom Lane
Subject Re: pgsql: Add a non-strict version of jsonb_set
Date
Msg-id 30906.1579304462@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Add a non-strict version of jsonb_set  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Responses Re: pgsql: Add a non-strict version of jsonb_set
List pgsql-committers
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
>> On Jan 17, 2020, at 12:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Shoulda been a catversion bump in here, if only for protocol's sake.

> I'd love to have a git pre-commit hook that would warn about this, it
> seems to happen several times a year, and I know I've transgressed
> more than once. Not sure what the rules should be, something like if
> you changed src/include/catalog/* but not
> src/include/catalog/catversion.h ?

Meh.  I think that would lead to forced catversion bumps even when
not necessary (ex: when just correcting description strings).
The cure could easily be worse than the disease.

In reality, the only reason for repeated catversion bumps during
development is to warn fellow developers that they have to do
an initdb after a git pull.  That's certainly a valuable courtesy,
but the sky generally isn't going to fall if you forget.

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?

            regards, tom lane



pgsql-committers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pgsql: Add a non-strict version of jsonb_set
Next
From: Michael Paquier
Date:
Subject: pgsql: Add GUC checks for ssl_min_protocol_version and ssl_max_protocol