From: | John W Higgins <wishdev(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: jsonb_set() strictness considered harmful to data |
Date: | 2019-10-20 21:09:36 |
Message-ID: | CAPhAwGwUH+uaC801Zw9_LEKU-djb2tTjM1SmCZ4+0rrj48c1gQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
>
>
> You're not following because you don't want to follow.
>
>
I think that anyone with a "commit bit" on this project that tolerates that
sentence is a much better human being than I ever will be.
I may be the dumbest person on this list by many measures - but isn't there
standard options that are supposed to be the first line of defense here?
Why do I need a function to ensure I don't remove data by passing a NULL
value to an update?
Why would any of these standard statements not solve this issue?
update users set info=jsonb_set(info, '{bar}', info->'foo')
where info->'foo' is not null
update users set info=jsonb_set(info, '{bar}', info->'foo')
where jsonb_set(info, '{bar}', info->'foo') is not null
update users set info=coalesce(jsonb_set(info, '{bar}', info->'foo'), info)
I can totally respect the person that slams into this wall the first time
and is REALLY upset about it - but by their own admission this has occurred
multiple times in this project and they continue to not take standard
precautions.
Again, I applaud the patience of many people on this list. You deserve much
more respect than you are being shown here right now.
John W Higgins
From | Date | Subject | |
---|---|---|---|
Next Message | Paul A Jungwirth | 2019-10-20 21:10:15 | Re: jsonb_set() strictness considered harmful to data |
Previous Message | Laurenz Albe | 2019-10-20 20:53:13 | Re: jsonb_set() strictness considered harmful to data |
From | Date | Subject | |
---|---|---|---|
Next Message | Paul A Jungwirth | 2019-10-20 21:10:15 | Re: jsonb_set() strictness considered harmful to data |
Previous Message | Laurenz Albe | 2019-10-20 21:06:32 | Re: pause recovery if pitr target not reached |