| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Ariadne Conill <ariadne(at)dereferenced(dot)org>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Christoph Moench-Tegeder <cmt(at)burggraben(dot)net>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, "feld(at)freebsd(dot)org" <feld(at)freebsd(dot)org> |
| Subject: | Re: jsonb_set() strictness considered harmful to data |
| Date: | 2019-10-19 05:41:24 |
| Message-ID: | CAKFQuwZRLKwfu4Tz3V68UYmvRb_6HKKTU7NJ5S_ZLmHq5+00=g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On Friday, October 18, 2019, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> Probably there will be some applications that needs NULL result in
> situations when value was not changed or when input value has not expected
> format. Design using in Postgres allows later customization - you can
> implement with COALESCE very simply behave that you want (sure, you have to
> know what you do). If Postgres implement design used by MySQL, then there
> is not any possibility to react on situation when update is not processed.
>
A CASE expression seems like it would work well for such detection in the
rare case it is needed. Current behavior is unsafe with minimal or no
redeeming qualities. Change it so passing in null raises an exception and
make the user decide their own behavior if we don’t want to choose one for
them.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2019-10-19 05:52:13 | Re: jsonb_set() strictness considered harmful to data |
| Previous Message | Pavel Stehule | 2019-10-19 04:17:39 | Re: jsonb_set() strictness considered harmful to data |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2019-10-19 05:52:13 | Re: jsonb_set() strictness considered harmful to data |
| Previous Message | tsunakawa.takay@fujitsu.com | 2019-10-19 05:03:00 | Fix of fake unlogged LSN initialization |