Re: jsonb concatenate operator's semantics seem questionable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Josh Berkus <josh(at)agliodbs(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, Ryan Pedela <rpedela(at)datalanche(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Ilya Ashchepkov <koctep(at)gmail(dot)com>
Subject: Re: jsonb concatenate operator's semantics seem questionable
Date: 2015-05-22 21:54:35
Message-ID: 14013.1432331675@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> writes:
> On 5/22/15 2:44 PM, Andrew Dunstan wrote:
>> Still I'd rather not add yet another parameter to the function, and I
>> certainly don't want to make throwing an error the only behaviour.

> If instead of a create_missing boolean it accepted an enum we could
> handle both (since they're related). But I'd also like to avoid Yet More
> Knobs if possible.

> I think there's essentially two scenarios for JSON usage; one where you
> want to be pretty paranoid about things like keys aren't missing, you're
> not trying to access a path that doesn't exist, etc. The other mode
> (what we have today) is when you really don't care much about that stuff
> and want the database to JustStoreIt. I don't know how many people would
> want the stricter mode, but it certainly seems painful to try and
> enforce that stuff today if you care about it.

ISTM that the use case for JSON is pretty much JustStoreIt. If you had
strict structural expectations you'd probably have chosen a more
relational representation in the first place ... or else XML, which at
least has heard of schemas and validation. So I definitely agree that
we need the no-error case, and am not that excited about having an
error-throwing variant.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2015-05-22 22:29:03 Re: Change pg_cancel_*() to ignore current backend
Previous Message Tom Lane 2015-05-22 21:51:03 Re: Change pg_cancel_*() to ignore current backend