On Fri, Jul 17, 2015 at 6:20 PM, Andrew Dunstan wrote:
> OK, I have committed this and updated the open issues list on the wiki.
Thanks, Andrew.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
On 07/17/2015 02:49 PM, Andrew Dunstan wrote:
On 07/17/2015 02:37 PM, Robert Haas wrote:
On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan
wrote:
Where are we on this? This is currently a 9.5 release blocker.
I am on vacation right now, but I might have some time tomorrow to
deal with
it. If
On 07/17/2015 02:37 PM, Robert Haas wrote:
On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote:
Where are we on this? This is currently a 9.5 release blocker.
I am on vacation right now, but I might have some time tomorrow to deal with
it. If not, it will be Sunday or Monday when I get to i
On Fri, Jul 17, 2015 at 11:37 AM, Robert Haas wrote:
>> I am on vacation right now, but I might have some time tomorrow to deal with
>> it. If not, it will be Sunday or Monday when I get to it.
>
> Is this still pending?
Yes.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-
On Thu, Jul 9, 2015 at 10:49 AM, Andrew Dunstan wrote:
>> Where are we on this? This is currently a 9.5 release blocker.
>
> I am on vacation right now, but I might have some time tomorrow to deal with
> it. If not, it will be Sunday or Monday when I get to it.
Is this still pending?
--
Robert
On Thu, Jul 9, 2015 at 7:49 AM, Andrew Dunstan wrote:
> I am on vacation right now, but I might have some time tomorrow to deal with
> it. If not, it will be Sunday or Monday when I get to it.
Okay. Thanks.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
On 07/09/2015 04:10 AM, Peter Geoghegan wrote:
On Mon, Jun 22, 2015 at 6:19 PM, Peter Geoghegan wrote:
On Wed, Jun 10, 2015 at 11:48 AM, Andrew Dunstan wrote:
Please submit a patch to adjust the treatment of negative integers in the
old functions to be consistent with their treatment in the
On Mon, Jun 22, 2015 at 6:19 PM, Peter Geoghegan wrote:
> On Wed, Jun 10, 2015 at 11:48 AM, Andrew Dunstan wrote:
>> Please submit a patch to adjust the treatment of negative integers in the
>> old functions to be consistent with their treatment in the new functions.
>> i.e. in the range [-n,-1]
On Wed, Jun 10, 2015 at 11:48 AM, Andrew Dunstan wrote:
> Please submit a patch to adjust the treatment of negative integers in the
> old functions to be consistent with their treatment in the new functions.
> i.e. in the range [-n,-1] they should refer to the corresponding element
> counting from
On 6/5/15 3:51 PM, Alvaro Herrera wrote:
Jim Nasby wrote:
On 6/5/15 2:08 PM, Petr Jelinek wrote:
That's a good point, and it won't get any better if/when we add the json
point support in 9.6 since the syntax would be something like select
jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' - '/c/a'; an
On Fri, Jun 12, 2015 at 4:31 PM, Andrew Dunstan wrote:
> OK, pushed, although you'd have to be trying really hard to break this.
> Still, it's reasonable to defend against.
I was trying really hard. :-)
Thanks
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 06/12/2015 06:16 PM, Peter Geoghegan wrote:
On Thu, Jun 4, 2015 at 5:43 PM, Peter Geoghegan wrote:
BTW, there is a bug here -- strtol() needs additional defenses [1]
(before casting to int):
postgres=# select jsonb_set('[1, 2, 3, 4,
5,6,7,8,9,10,11,12,13,14,15,16,17,18]',
'{"92233720368547
On Thu, Jun 4, 2015 at 5:43 PM, Peter Geoghegan wrote:
>
> BTW, there is a bug here -- strtol() needs additional defenses [1]
> (before casting to int):
>
> postgres=# select jsonb_set('[1, 2, 3, 4,
> 5,6,7,8,9,10,11,12,13,14,15,16,17,18]',
> '{"9223372036854775806"}'::text[], '"Input unsanitized"
On Fri, Jun 12, 2015 at 12:26 PM, Andrew Dunstan wrote:
> Here's some code for the count piece of that.
Thanks. I'll look into integrating this with what I have.
BTW, on reflection I'm not so sure about my decision to not touch the
logic within jsonb_delete_idx() (commit b81c7b409). I probably s
On 06/12/2015 12:29 PM, I wrote:
I agree that the json case looks a bit nasty. Maybe a better approach
would be to provide a function that, given a JsonLexContext, returns
the number of array elements of the current array. In get_array_start
we could call that if the relevant path element
On 06/10/2015 04:02 PM, Peter Geoghegan wrote:
On Wed, Jun 10, 2015 at 11:48 AM, Andrew Dunstan wrote:
Sorry for the delay on this. I've been mostly off the grid, having an all
too rare visit from Tom "Mr Enum" Dunstan, and I misunderstood what you were
suggesting,
Thank you for working with
On Wed, Jun 10, 2015 at 11:48 AM, Andrew Dunstan wrote:
> Sorry for the delay on this. I've been mostly off the grid, having an all
> too rare visit from Tom "Mr Enum" Dunstan, and I misunderstood what you were
> suggesting,
Thank you for working with me to address this. I've been busy with
other
On 06/05/2015 01:51 PM, Andrew Dunstan wrote:
On 06/05/2015 01:39 PM, Peter Geoghegan wrote:
On Thu, Jun 4, 2015 at 12:10 PM, Peter Geoghegan wrote:
But I agree that it's not a great contribution to science,
especially since
the index will be applied to the list of elements in the somewhat
On 06/05/2015 04:48 PM, Tom Lane wrote:
Andrew Dunstan writes:
Yeah, Good point. Actually, if my memory serves me correctly (always a
dubious bet), the avoidance of that kind of ambiguity is why we
introduced the #> and #>> operators in the first place, after going
round and round for a while
On Fri, Jun 5, 2015 at 1:05 PM, Andrew Dunstan wrote:
> So probably the least invasive change would be to rename the text[] variant
> operator to something like "#-" and rename the corresponding function to
> jsonb_delete_path.
>
> We could also decide not to keep an operator at all, on the ground
On Fri, Jun 5, 2015 at 10:51 AM, Andrew Dunstan wrote:
>>> Also, what about negative array subscripting (making the 9.4-era
>>> "operator jsonb -> integer" operator support that for consistency with
>>> the new "operator jsonb - integer" operator)? Should I write the
>>> patch? Will you commit it
Andrew Dunstan writes:
> Yeah, Good point. Actually, if my memory serves me correctly (always a
> dubious bet), the avoidance of that kind of ambiguity is why we
> introduced the #> and #>> operators in the first place, after going
> round and round for a while on what the API would look like.
On 06/05/2015 02:32 PM, Alvaro Herrera wrote:
'some jsonb value' - '{foo,bar}' is already ambiguous - the RH operand
could be a single text datum or a text array.
Hmm, but that's not in 9.4, so we can still tweak it if necessary.
Consider this jsonb datum. Nobody in their right mind would ha
Jim Nasby wrote:
> On 6/5/15 2:08 PM, Petr Jelinek wrote:
> >That's a good point, and it won't get any better if/when we add the json
> >point support in 9.6 since the syntax would be something like select
> >jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' - '/c/a'; and we will again
> >silently do not
On 6/5/15 2:08 PM, Petr Jelinek wrote:
That's a good point, and it won't get any better if/when we add the json
point support in 9.6 since the syntax would be something like select
jsonb '{"a":"1", "b":"2", "c": {"a": "2"}}' - '/c/a'; and we will again
silently do nothing. That's going to cause b
On Fri, Jun 5, 2015 at 8:32 , Alvaro Herrera
wrote:
Andrew Dunstan wrote:
'some jsonb value' - '{foo,bar}' is already ambiguous - the RH
operand
could be a single text datum or a text array.
Hmm, but that's not in 9.4, so we can still tweak it if necessary.
Consider this jsonb datum. N
Andrew Dunstan wrote:
>
> On 06/04/2015 03:16 PM, Alvaro Herrera wrote:
> >I'm just skimming here, but if a jsonb_path type is being proposed,
> >perhaps it would be better not to have operators that take text or
> >text[] as second argument. We can provide that functionality with just
> >functio
On 06/05/2015 01:39 PM, Peter Geoghegan wrote:
On Thu, Jun 4, 2015 at 12:10 PM, Peter Geoghegan wrote:
But I agree that it's not a great contribution to science, especially since
the index will be applied to the list of elements in the somewhat
counter-intuitive storage order we use, and we co
On Thu, Jun 4, 2015 at 12:10 PM, Peter Geoghegan wrote:
>> But I agree that it's not a great contribution to science, especially since
>> the index will be applied to the list of elements in the somewhat
>> counter-intuitive storage order we use, and we could just raise an error if
>> we try to ap
On 06/04/2015 03:16 PM, Alvaro Herrera wrote:
I'm just skimming here, but if a jsonb_path type is being proposed,
perhaps it would be better not to have operators that take text or
text[] as second argument. We can provide that functionality with just
functions. For example, it will be confusi
On Thu, Jun 4, 2015 at 5:31 PM, Andrew Dunstan wrote:
> Just in case it's not clear: I am not at all happy.
I've offered to help you with several of the issue I raised; I had
intended to offer more help.
The issues I raise seem pretty substantive to me. I'm trying to make
sure that we don't end
On Thu, Jun 4, 2015 at 12:10 PM, Peter Geoghegan wrote:
> jsonb_delete() should certainly be able to traverse objects, but it's
> much less clear that it should be able to *traverse* arrays (affecting
> arrays is a different story, though). That's why I proposed not
> supporting traversing arrays
On 06/04/2015 03:10 PM, Peter Geoghegan wrote:
On Thu, Jun 4, 2015 at 6:43 AM, Andrew Dunstan wrote:
I've noticed some more issues with the jsonb documentation, and the
new jsonb stuff generally. I didn't set out to give Andrew feedback on
the semantics weeks after feature freeze, but unfortun
On 06/04/2015 04:13 PM, David E. Wheeler wrote:
On Jun 4, 2015, at 12:16 PM, Alvaro Herrera wrote:
I'm just skimming here, but if a jsonb_path type is being proposed,
Is this not the purpose of JSQuery?
https://code.google.com/p/gwtquery/wiki/JsQuery
No, it doesn't seem to have anyth
On Jun 4, 2015, at 12:16 PM, Alvaro Herrera wrote:
> I'm just skimming here, but if a jsonb_path type is being proposed,
Is this not the purpose of JSQuery?
https://code.google.com/p/gwtquery/wiki/JsQuery
David
smime.p7s
Description: S/MIME cryptographic signature
On Thu, Jun 4, 2015 at 1:02 PM, Peter Geoghegan wrote:
> I would like these new-to-9.5 deletion operators to work at the top
> level only, like "operator jsonb ? text" and "operator jsonb ?| text",
> sharing their idea of a key, __including that string array elements
> are keys__. We haven't got a
On Thu, Jun 4, 2015 at 12:16 PM, Alvaro Herrera
wrote:
> I'm just skimming here, but if a jsonb_path type is being proposed,
> perhaps it would be better not to have operators that take text or
> text[] as second argument. We can provide that functionality with just
> functions. For example, it
I'm just skimming here, but if a jsonb_path type is being proposed,
perhaps it would be better not to have operators that take text or
text[] as second argument. We can provide that functionality with just
functions. For example, it will be confusing to have
jsonb 'some json value' - '{foo,bar}
On Thu, Jun 4, 2015 at 6:43 AM, Andrew Dunstan wrote:
>> I've noticed some more issues with the jsonb documentation, and the
>> new jsonb stuff generally. I didn't set out to give Andrew feedback on
>> the semantics weeks after feature freeze, but unfortunately this feels
>> like another discussio
On 06/04/2015 11:33 AM, Jim Nasby wrote:
On 6/4/15 8:43 AM, Andrew Dunstan wrote:
You are conflating two different things here, quite pointlessly. The RH
operand of ?| is not a path, whereas the RH operand of this - variant
is. The fact that they are both text arrays doesn't mean that they
shou
On 6/4/15 8:43 AM, Andrew Dunstan wrote:
You are conflating two different things here, quite pointlessly. The RH
operand of ?| is not a path, whereas the RH operand of this - variant
is. The fact that they are both text arrays doesn't mean that they
should mean the same thing. And this is really
On 06/03/2015 10:02 PM, Peter Geoghegan wrote:
I've noticed some more issues with the jsonb documentation, and the
new jsonb stuff generally. I didn't set out to give Andrew feedback on
the semantics weeks after feature freeze, but unfortunately this feels
like another discussion that we need to
On Wed, Jun 3, 2015 at 7:02 PM, Peter Geoghegan wrote:
> Consider this case:
>
> postgres=# select '{"c":5, "a":6, "b":7}'::jsonb - 1;
> ?column?
> --
> {"a": 6, "c": 5}
> (1 row)
>
> Clearly anyone expecting the value "a" to be removed here would be in
> for a surprise. More
I've noticed some more issues with the jsonb documentation, and the
new jsonb stuff generally. I didn't set out to give Andrew feedback on
the semantics weeks after feature freeze, but unfortunately this feels
like another discussion that we need to have now rather than later.
"operator jsonb - in
44 matches
Mail list logo
