From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Floris Van Nee <florisvannee(at)optiver(dot)com>, Ariadne Conill <ariadne(at)dereferenced(dot)org>, Mark Felder <feld(at)freebsd(dot)org>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: jsonb_set() strictness considered harmful to data |
Date: | 2019-11-15 20:45:59 |
Message-ID: | CAFj8pRBrX6jQb-gUR=d8frWAEBuj5i0efxJ2509hK13aQbzNLg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
pá 15. 11. 2019 v 21:01 odesílatel Andrew Dunstan <
andrew(dot)dunstan(at)2ndquadrant(dot)com> napsal:
>
> On 11/15/19 2:14 PM, Pavel Stehule wrote:
> > Hi
> >
> >
> >
> > For release 13+, I have given some more thought to what should be
> > done.
> > I think the bar for altering the behaviour of a function should be
> > rather higher than we have in the present case, and the longer the
> > function has been sanctioned by time the higher the bar should be.
> > However, I think there is a case to be made for providing a
> non-strict
> > jsonb_set type function. To advance th4e discussion, attached is a
> POC
> > patch that does that. This can also be done as an extension, meaning
> > that users of back branches could deploy it immediately. I've tested
> > this against release 12, but I think it could go probably all the way
> > back to 9.5. The new function is named jsonb_ set_lax, but I'm open
> to
> > bikeshedding.
> >
> >
> > I am sending a review of this patch
> >
> > 1. this patch does what was proposed and it is based on discussion.
> >
> > 2. there are not any problem with patching or compilation, all regress
> > tests passed.
> >
> > 4. code looks well and it is well commented.
> >
> > 5. the patch has enough regress tests
> >
> > My notes:
> >
> > a) missing documentation
> >
> > b) error message is not finalized
> >
> > + ereport(ERROR,
> > + (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> > + errmsg("null jsonb value")));
> >
> > Any other looks well, and this function can be very handy.
> >
> >
>
> Thanks for the review. I will add some docco.
>
>
> What would be a better error message? "null jsonb replacement not
> permitted"?
>
Maybe ERRCODE_NULL_VALUE_NOT_ALLOWED, and "NULL is not allowed",
errdetail - a exception due setting "null_value_treatment" =>
raise_exception
and maybe some errhint - "Maybe you would to use Jsonb NULL - "null"::jsonb"
I don't know, but in this case, the exception should be verbose. This is
"rich" function with lot of functionality
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan https://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | John Lumby | 2019-11-15 20:57:14 | Re: access to original-statement predicates in an INSTEAD-OF row trigger |
Previous Message | Thomas Munro | 2019-11-15 20:32:51 | Re: here does postgres take its timezone information from? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-15 21:22:17 | Re: Removing pg_pltemplate and creating "trustable" extensions |
Previous Message | Andrew Dunstan | 2019-11-15 20:01:19 | Re: jsonb_set() strictness considered harmful to data |