Re: [HACKERS] [PATCH] Generic type subscripting - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: [HACKERS] [PATCH] Generic type subscripting
Date
Msg-id CA+q6zcXpCqQmW+n74pjLY1R5QaGx-5C39AUt==8twEbS5F3PsA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Generic type subscripting  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] [PATCH] Generic type subscripting  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
> On Wed, 7 Nov 2018 at 17:09, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
> I don't agree. If we use a  same syntax for some objects types, we should to enforce some consistency.

Just to make it clear, consistency between what?

> I don't think so you should to introduce nulls for JSONs. In this case, the most correct solution is raising a
exception.

Now it's my turn to disagree. As an argument I have this thread [1], where
similar discussion happened about flexibility of jsonb and throwing an errors
(in this particular case whether or not to throw an error when a non existing
path was given to jsonb_set).

I can imagine significant number of use cases when adding a value to jsonb like
that is desirable outcome, and I'm not sure if I can come up with an example
when strictness is the best result. Maybe if you have something in mind, you
can describe what would be the case for that? Also as I've mentioned before,
consistency between jsonb_set and jsonb subscripting operator will help us to
avoid tons of question about why I can do this and this using one option, but
not another.

[1]: https://www.postgresql.org/message-id/CAM3SWZT3uZ7aFktx-nNEWGbapN1oy2t2gt10pnOzygZys_Ak1Q%40mail.gmail.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: partitioned indexes and tablespaces
Next
From: Robert Haas
Date:
Subject: Re: ATTACH/DETACH PARTITION CONCURRENTLY