On Wed, Jan 8, 2020 at 7:08 AM Pavel Stehule wrote:
>
> Hi
>
> po 6. 1. 2020 v 22:34 odesílatel Andrew Dunstan
> napsal:
>>
>>
>> Updated version including docco and better error message.
>>
>> cheers
>>
>> andrew
>
>
> I think s
On Thu, Nov 28, 2019 at 2:15 PM Andrew Dunstan
wrote:
>
>
> On 11/27/19 9:35 PM, Michael Paquier wrote:
> > On Fri, Nov 15, 2019 at 09:45:59PM +0100, Pavel Stehule wrote:
> >> Maybe ERRCODE_NULL_VALUE_NOT_ALLOWED, and "NULL is not allowed",
> &
atch is waiting on input from you for a couple of days
> now.
>
Will get to this on Friday - tomorrow is Thanksgiving so I'm unlikely to
get to it then.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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"?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/21/19 9:28 AM, Andrew Dunstan wrote:
> On 10/21/19 2:07 AM, Tomas Vondra wrote:
>> On Sun, Oct 20, 2019 at 06:51:05PM -0400, Andrew Dunstan wrote:
>>>> I think the general premise of this thread is that the application
>>>> developer does not realize that
On 10/21/19 2:07 AM, Tomas Vondra wrote:
> On Sun, Oct 20, 2019 at 06:51:05PM -0400, Andrew Dunstan wrote:
>>
>>> I think the general premise of this thread is that the application
>>> developer does not realize that may be necessary, because it's a bit
>>&g
On 10/20/19 4:18 PM, Tomas Vondra wrote:
> On Sun, Oct 20, 2019 at 03:48:05PM -0400, Andrew Dunstan wrote:
>>
>> On 10/20/19 1:14 PM, David G. Johnston wrote:
>>> On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan
>>> >> <mailto:andrew.duns...@2ndquadrant.c
On 10/20/19 1:14 PM, David G. Johnston wrote:
> On Sun, Oct 20, 2019 at 5:31 AM Andrew Dunstan
> <mailto:andrew.duns...@2ndquadrant.com>> wrote:
>
> And yet another is to
> raise an exception, which is easy to write but really punts the issue
> back to the
meter. Possibly we could even add an extra
parameter to specify what should be done.
Also, the question will arise what to do when any of the other
parameters are NULL. Should we return NULL in those cases as we do now?
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.
able argument in the first
> place, and can reasonably safely and effectively prevent it going
> forward. Then people will have to explicitly code what they want to
> do if their data and queries present this invalid unknown data to the
> function.
>
>
How exactly do we prevent a NULL being passed as an argument? The only
thing we could do would be to raise an exception, I think. That seems
like a fairly ugly thing to do, I'd need a h3eck of a lot of convincing.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10/19/19 12:18 PM, Tomas Vondra wrote:
> On Sat, Oct 19, 2019 at 11:26:50AM -0400, Andrew Dunstan wrote:
>
> Not sure, but that seems rather confusing to me, because it's mixing SQL
> NULL and JSON null, i.e. it's not clear to me why
>
> jsonb_set(..., ".
hat policy that
is in large measure responsible for Postgres' deserved reputation for
stability.
Incidentally, why is your function written in plpgsql? Wouldn't a simple
SQL wrapper be better?
create or replace function safe_jsonb_set
(target jsonb, path text[], new_value jsonb, create_missing
boolean default true)
returns jsonb as
$func$
select case when new_value is null then target else
jsonb_set(target, path, new_value, create_missing) end
$func$ language sql;
And if we were to change it I'm not at all sure that we should do it the
way that's suggested here, which strikes me as no more intuitive than
the current behaviour. Rather I think we should possibly fill in a json
null in the indicated place.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
mi-reliable rule of thumb.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ffort!
Yeah. The crowd also seemed noticeably more diverse than I have usually
seen at Postgres conferences. That's a small beginning, but it's a
welcome development.
cheers
andrew
--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remot
14 matches
Mail list logo
