On 05/24/2015 03:17 PM, Peter Geoghegan wrote:
On Thu, May 21, 2015 at 2:25 PM, Andrew Dunstan and...@dunslane.net wrote:
This change really makes this set of jsonb features quite a bit more
compelling. I'm glad I thought of it - wish I had done so earlier. So
notwithstanding the controversy
On Thu, May 21, 2015 at 2:25 PM, Andrew Dunstan and...@dunslane.net wrote:
This change really makes this set of jsonb features quite a bit more
compelling. I'm glad I thought of it - wish I had done so earlier. So
notwithstanding the controversy upthread, I think this is a good result.
I think
Andres Freund and...@anarazel.de writes:
On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote:
Having gone to the trouble of making the parser support this stuff (in
a way that makes us not follow the SQL standard in a couple of
places), we ought to have a similar capability for jsonb. I
On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote:
Having gone to the trouble of making the parser support this stuff (in
a way that makes us not follow the SQL standard in a couple of
places), we ought to have a similar capability for jsonb. I haven't
looked into it, but it seems like a
On 05/24/2015 05:38 PM, Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 2015-05-24 12:17:35 -0700, Peter Geoghegan wrote:
Having gone to the trouble of making the parser support this stuff (in
a way that makes us not follow the SQL standard in a couple of
places), we ought to have
Jim Nasby jim.na...@bluetreble.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
On Fri, May 22, 2015 at 2:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On 5/22/15 2:44 PM, Andrew Dunstan wrote:
On 05/22/2015 03:27 PM, Peter Geoghegan wrote:
On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan and...@dunslane.net
wrote:
As for raising an error, in principle it's doable, but the code to
detect it
might get messy. Also, I don't want a huge number
On 5/22/15 4:54 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.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
On 05/22/2015 03:27 PM, Peter Geoghegan wrote:
On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan and...@dunslane.net wrote:
As for raising an error, in principle it's doable, but the code to detect it
might get messy. Also, I don't want a huge number of knobs. So I'm excited
about the idea.
I
On 5/21/15 4:25 PM, Andrew Dunstan wrote:
Here is a patch that renames jsonb_replace to jsonb_set with a boolean
create_missing flag that defaults to false (should we default it to
true?). With the flag set it's more or less upsert for jsonb. Without,
it's just update.
I think upsert is
On 05/22/2015 02:38 PM, Jim Nasby wrote:
On 5/21/15 4:25 PM, Andrew Dunstan wrote:
Here is a patch that renames jsonb_replace to jsonb_set with a boolean
create_missing flag that defaults to false (should we default it to
true?). With the flag set it's more or less upsert for jsonb. Without,
On Fri, May 22, 2015 at 11:59 AM, Andrew Dunstan and...@dunslane.net wrote:
As for raising an error, in principle it's doable, but the code to detect it
might get messy. Also, I don't want a huge number of knobs. So I'm excited
about the idea.
I think that that's a bad default behavior,
On Tue, May 19, 2015 at 10:43 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I am of strong opinion that concat should be shallow by default. Again it's
how jquery works by default, it's how python's dict.update works and you can
find this behavior in other languages as well when dealing with
Petr Jelinek wrote:
On 20/05/15 01:38, Jim Nasby wrote:
If we get this wrong now, we'll be stuck with it forever. At a minimum I
think we should use anything other than || until we can figure this out.
That leaves || available for whichever case we decide on.
I am of strong opinion that
On 05/20/2015 02:11 AM, Peter Geoghegan wrote:
On Tue, May 19, 2015 at 10:43 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I am of strong opinion that concat should be shallow by default. Again it's
how jquery works by default, it's how python's dict.update works and you can
find this behavior
It is like bugfix than new feature
Dne 20.5.2015 21:08 napsal uživatel Josh Berkus j...@agliodbs.com:
On 05/20/2015 11:34 AM, Andrew Dunstan wrote:
So Dmitry, at my suggestion, has come up with a way of doing that, by
adding a parameter to jsonb_replace(). If this parameter is set to true
Josh Berkus j...@agliodbs.com writes:
That does cover all bases, and users would be able to create the
operator which suits their particular use case easily. It's also fairly
similar to how jsquery works, although the syntax is completely different.
But ... it's after feature freeze. So,
On 05/20/2015 03:37 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
That does cover all bases, and users would be able to create the
operator which suits their particular use case easily. It's also fairly
similar to how jsquery works, although the syntax is completely different.
But
On Wed, May 20, 2015 at 12:34 PM, Andrew Dunstan and...@dunslane.net
wrote:
So Dmitry, at my suggestion, has come up with a way of doing that, by
adding a parameter to jsonb_replace(). If this parameter is set to true (it
defaults to false) and the key or array element pointed to by the last
On 05/20/2015 11:34 AM, Andrew Dunstan wrote:
So Dmitry, at my suggestion, has come up with a way of doing that, by
adding a parameter to jsonb_replace(). If this parameter is set to true
(it defaults to false) and the key or array element pointed to by the
last element of the path doesn't
On 2015-05-20 15:37:15 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
That does cover all bases, and users would be able to create the
operator which suits their particular use case easily. It's also fairly
similar to how jsquery works, although the syntax is completely
On 20/05/15 01:38, Jim Nasby wrote:
On 5/18/15 3:15 PM, Marko Tiikkaja wrote:
On 2015-05-18 22:10, Josh Berkus wrote:
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
In the context of splitting shallow and deep merge into two
operators, I
think + is better for shallow and || better for deep. The
On 5/18/15 3:15 PM, Marko Tiikkaja wrote:
On 2015-05-18 22:10, Josh Berkus wrote:
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
In the context of splitting shallow and deep merge into two operators, I
think + is better for shallow and || better for deep. The reason for +
is because many
On Sun, May 17, 2015 at 9:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS or other client languages which would make that
preference make more sense
On 05/18/2015 12:11 AM, Peter Geoghegan wrote:
On Sun, May 17, 2015 at 8:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS or other client languages
18.05.2015, 06:41, Josh Berkus kirjoitti:
On 05/17/2015 05:46 PM, Robert Haas wrote:
On May 17, 2015, at 8:38 PM, Peter Geoghegan p...@heroku.com wrote:
The current behavior does not seem acceptable for the concatenate
operator (operator || jsonb).
I don't agree. It seems pretty clear to me
On Mon, May 18, 2015 at 5:05 AM, Andrew Dunstan and...@dunslane.net wrote:
As between || and + I'm personally moderately indifferent. I think you're
representing some body of understanding about the effects of certain
operators as being widespread when that's very far from clear.
You really
On 05/18/2015 01:18 PM, Peter Geoghegan wrote:
So I think we should use the + operator to distance this from the
hstore concatenate operator, which *is* widely understood to be mostly
useful for nested assignment.
Having trouble scanning this. Since hstore isn't nested what the heck
does
On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
Having trouble scanning this. Since hstore isn't nested what the heck does
nested assignment mean w.r.t. hstore?
It means assigning to one subdatum in the hstore datum, as opposed
to simply assigning an entirely new
On Mon, May 18, 2015 at 8:41 AM, Ryan Pedela rped...@datalanche.com wrote:
On Sun, May 17, 2015 at 9:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS
creates the specified path if it does not exist. Does it?
No, jsonb_replace() doesn't create an element, if it doesn't exist. I
think, otherwise it can be confusing, so probably jsonb_add() may be more
appropriate (and, actually, this function was already mentioned in previous
discussions).
On
On 05/18/2015 01:43 PM, Peter Geoghegan wrote:
On Mon, May 18, 2015 at 10:29 AM, Andrew Dunstan and...@dunslane.net wrote:
Having trouble scanning this. Since hstore isn't nested what the heck does
nested assignment mean w.r.t. hstore?
It means assigning to one subdatum in the hstore datum,
On 05/17/2015 09:11 PM, Peter Geoghegan wrote: As I said, I don't think
that my preference for deep concatenation is
a matter of taste. I think that shallow concatenation is fundamentally
and objectively at odds with what jsonb is supposed to be (as long as
concatenation is the way nested
On Mon, May 18, 2015 at 11:24 AM, Josh Berkus j...@agliodbs.com wrote:
On 05/17/2015 09:11 PM, Peter Geoghegan wrote: As I said, I don't think
that my preference for deep concatenation is
a matter of taste. I think that shallow concatenation is fundamentally
and objectively at odds with what
On 05/18/2015 11:34 AM, Peter Geoghegan wrote:
I'm not necessarily attached to +. I just want to make this
different to hstore's || operator. There should be a similar idiom
with jsonb, but that can come later.
This argument still makes no sense to me. Hstore is not nested. If
anything, the
On Mon, May 18, 2015 at 11:16 AM, Andrew Dunstan and...@dunslane.net wrote:
I could argue at least as convincingly that what the jsonb || operator does
is exactly analogous to what hstore's || does.
Again, my concern is not primarily a theoretical one. It's primarily a
practical concern. We are
On 05/18/2015 02:45 PM, Josh Berkus wrote:
On 05/18/2015 11:34 AM, Peter Geoghegan wrote:
I'm not necessarily attached to +. I just want to make this
different to hstore's || operator. There should be a similar idiom
with jsonb, but that can come later.
This argument still makes no sense to
On Mon, May 18, 2015 at 11:45 AM, Josh Berkus j...@agliodbs.com wrote:
On 05/18/2015 11:34 AM, Peter Geoghegan wrote:
I'm not necessarily attached to +. I just want to make this
different to hstore's || operator. There should be a similar idiom
with jsonb, but that can come later.
This
On 05/18/2015 11:58 AM, Peter Geoghegan wrote:
As you say, hstore isn't nested, and so this simply doesn't come up
there. We have failed to adopt || to jsonb in a way that makes
sense. We should have adopted it to jsonb in exactly the same way as
the @ operator was.
OK, you've flagellated
On Mon, May 18, 2015 at 12:12 PM, Josh Berkus j...@agliodbs.com wrote:
OK, you've flagellated this deceased equine enough that I'm calling the
ASPCA. I get that you're unhappy that we don't have deep append.
Everyone gets this. I simply don't care; shallow append is better than
no append at
On 05/18/2015 03:21 PM, Peter Geoghegan wrote:
The only question worth discussing is whether we change the operator to
+ (or, for that matter, something else). I've seen your vote on this,
so, does anyone else have an opinion on + vs. ||? Preferably with a
justification with some kind of
On Mon, May 18, 2015 at 3:21 PM, Peter Geoghegan p...@heroku.com wrote:
What is hard to understand about that?
What is hard to understand is why you're going on and on about what is
basically a matter of opinion after several people have said they
don't agree with your opinion.
Realistically,
On Mon, May 18, 2015 at 12:24 PM, Josh Berkus j...@agliodbs.com wrote:
On 05/18/2015 08:57 AM, Ryan Pedela wrote:
If not, deep concatenation would solve this problem, but I can also see
another solution. Use + for shallow concatenation since it really means
add element to top-level path as
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
Let me back up a little. I always like to think about what is the ideal
interface first and then worry about implementation because
implementation can always be changed but interface can't. I think the
current concat/merge interface is the ideal. It
On Mon, May 18, 2015 at 1:19 PM, Catalin Iacob iacobcata...@gmail.com wrote:
In hstore @ means unnested containment, in jsonb it means nested
containment. Therefore, when an hstore operator is applied to jsonb it gets
nestedness as jsonb is nested and adds that nestedness is an important
thing
On Mon, May 18, 2015 at 9:03 PM Andrew Dunstan and...@dunslane.net wrote:
So you're arguing that we shouldn't call the operation in question ||
because it's pretty much the same, mutatis mutandis, as the hstore
operation of the same name. You've lost me.
Hopefully this helps. Peter's
On 2015-05-18 22:10, Josh Berkus wrote:
On 05/18/2015 01:04 PM, Ryan Pedela wrote:
In the context of splitting shallow and deep merge into two operators, I
think + is better for shallow and || better for deep. The reason for +
is because many programming languages have this behavior. If I see
On Mon, May 18, 2015 at 1:03 PM, Robert Haas robertmh...@gmail.com wrote:
Realistically, as much as we might try to fool ourselves into
believing otherwise, operators are not self-documenting, except for
the ones you knew by the fourth grade. People will have to read the
documentation no
On 05/18/2015 04:54 PM, David G. Johnston wrote:
On Mon, May 18, 2015 at 12:12 PM, Josh Berkus j...@agliodbs.com
mailto:j...@agliodbs.comwrote:
On 05/18/2015 11:58 AM, Peter Geoghegan wrote:
As you say, hstore isn't nested, and so this simply doesn't come up
there. We have
On 17/05/15 16:04, Andrew Dunstan wrote:
On 05/16/2015 10:56 PM, Peter Geoghegan wrote:
Another thing that I noticed about the new jsonb stuff is that the
concatenate operator is based on the hstore one. This works as
expected:
postgres=# select '{a:1}'::jsonb || '{a:2}';
?column?
--
On May 17, 2015, at 8:38 PM, Peter Geoghegan p...@heroku.com wrote:
The current behavior does not seem acceptable for the concatenate
operator (operator || jsonb).
I don't agree. It seems pretty clear to me after reading the new posts that
the behavior is not an oversight, and that's enough
On Sun, May 17, 2015 at 5:46 PM, Robert Haas robertmh...@gmail.com wrote:
On May 17, 2015, at 8:38 PM, Peter Geoghegan p...@heroku.com wrote:
The current behavior does not seem acceptable for the concatenate
operator (operator || jsonb).
I don't agree. It seems pretty clear to me after
On Sun, May 17, 2015 at 3:22 PM, Andrew Dunstan and...@dunslane.net wrote:
So what exactly do you want me or anybody else to do now, two days *after*
we declared (not without pain) feature freeze?
As much as I'd like to just fix the concatenate operator, I really
don't want to be the person
On Sun, May 17, 2015 at 7:16 AM, Petr Jelinek p...@2ndquadrant.com wrote:
Agreed, if you look at jquery for example, the extend() method by default
behaves like our current || and you have to specify that you want deep merge
if you want the behavior described by Peter. So there is definitely
On Sun, May 17, 2015 at 8:37 AM, Dmitry Dolgov 9erthali...@gmail.com wrote:
And I agree with thoughts above, that both concatenation modes (simple and
deep) definitely can be useful. I can try to figure out how much work that
would be to modify the IteratorConcat function (or adapt Ilya's
On 05/17/2015 05:56 PM, Peter Geoghegan wrote:
On Sun, May 17, 2015 at 8:37 AM, Dmitry Dolgov 9erthali...@gmail.com wrote:
And I agree with thoughts above, that both concatenation modes (simple and
deep) definitely can be useful. I can try to figure out how much work that
would be to modify
On 05/17/2015 05:46 PM, Robert Haas wrote:
On May 17, 2015, at 8:38 PM, Peter Geoghegan p...@heroku.com wrote:
The current behavior does not seem acceptable for the concatenate
operator (operator || jsonb).
I don't agree. It seems pretty clear to me after reading the new posts that
the
On Sun, May 17, 2015 at 8:41 PM, Josh Berkus j...@agliodbs.com wrote:
Is there a particular reason why + makes more sense as shallow
concatination and || makes more sense as deep concatination? Like,
something in JS or other client languages which would make that
preference make more sense to
Historical note: I think it's based on the nested hstore work, not on
current hstore, but Dmitry can answer on that.
Yes, you're right.
And I agree with thoughts above, that both concatenation modes (simple
and deep) definitely can be useful. I can try to figure out how much work
that would be
On May 16, 2015, at 10:56 PM, Peter Geoghegan p...@heroku.com wrote:
Another thing that I noticed about the new jsonb stuff is that the
concatenate operator is based on the hstore one. This works as
expected:
postgres=# select '{a:1}'::jsonb || '{a:2}';
?column?
--
{a: 2}
(1
On 05/16/2015 10:56 PM, Peter Geoghegan wrote:
Another thing that I noticed about the new jsonb stuff is that the
concatenate operator is based on the hstore one. This works as
expected:
postgres=# select '{a:1}'::jsonb || '{a:2}';
?column?
--
{a: 2}
(1 row)
However, the nesting
Another thing that I noticed about the new jsonb stuff is that the
concatenate operator is based on the hstore one. This works as
expected:
postgres=# select '{a:1}'::jsonb || '{a:2}';
?column?
--
{a: 2}
(1 row)
However, the nesting doesn't match up -- containers are not merged
beyond
63 matches
Mail list logo
