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
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 |