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
43 matches
Mail list logo
