On Thu, January 30, 2014 20:07, Andrew Dunstan wrote:
>
> Updated patches for both pieces. Included is some tidying done by
>
> [ nested-hstore-9.patch.gz ]
Here is a small doc-patch to Table F-6. hstore Operators
It corrects its booleans in the 'Result' column ( t and f instead of true and
On 01/30/2014 01:50 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
We'd have to move that code from hstore to jsonb_support.c and then
make hstore refer to it.
Or just copy it and leave hstore alone - the
Andrew Dunstan writes:
> On 01/30/2014 01:03 PM, Hannu Krosing wrote:
>> On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
>>> We'd have to move that code from hstore to jsonb_support.c and then
>>> make hstore refer to it.
>> Or just copy it and leave hstore alone - the code duplication is not
>> te
On 01/30/2014 01:03 PM, Hannu Krosing wrote:
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan
wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for
On 01/30/2014 06:45 PM, Andrew Dunstan wrote:
>
> On 01/30/2014 12:34 PM, Merlin Moncure wrote:
>> On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan
>> wrote:
> Now, if we're agreed on that, I then also wonder if the 'as_text'
> argument needs to exist at all for the populate functions excep
On 01/30/2014 12:34 PM, Merlin Moncure wrote:
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan wrote:
Now, if we're agreed on that, I then also wonder if the 'as_text'
argument needs to exist at all for the populate functions except for
backwards compatibility on the json side (not jsonb). For
On Thu, Jan 30, 2014 at 9:50 AM, Andrew Dunstan wrote:
>>> Now, if we're agreed on that, I then also wonder if the 'as_text'
>>> argument needs to exist at all for the populate functions except for
>>> backwards compatibility on the json side (not jsonb). For non-complex
>>> structures it does be
ok, great. This is really fabulous. So far most everything feels
natural and good.
I see something odd in terms of the jsonb use case coverage. One of
the major headaches with json deserialization presently is that
there's no easy way to easily move a complex (record- or array-
containing)
On 01/29/2014 02:37 PM, Merlin Moncure wrote:
> create table bar(a int, b int[]);
> postgres=# select jsonb_populate_record(null::bar, '{"a": 1, "b":
> [1,2]}'::jsonb, false);
> ERROR: cannot populate with a nested object unless use_json_as_text is true
Hmmm. What about just making any impossibly
On 01/29/2014 05:37 PM, Merlin Moncure wrote:
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan wrote:
On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hsto
On Wed, Jan 29, 2014 at 3:56 PM, Andrew Dunstan wrote:
>
> On 01/29/2014 01:03 PM, Andrew Dunstan wrote:
>>
>>
>> On 01/27/2014 10:43 PM, Andrew Dunstan wrote:
>>>
>>>
>>> On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
>>
On 01/29/2014 12:46 PM, Merlin Moncure wrote:
> I think the opening paragraphs contrasting json/jsonb be needs
> refinement. json is going to be slightly faster than jsonb for input
> *and* output. For example, in one application I store fairly large
> json objects containing pre-compiled static
On Wed, Jan 29, 2014 at 12:03 PM, Andrew Dunstan wrote:
> Only change in functionality is the addition of casts between jsonb and
> json.
>
> The other changes are the merge with the new json functions code, and
> rearrangement of the docs changes to make them less ugly. Essentially I
> moved the
On 01/28/2014 10:56 AM, Alvaro Herrera wrote:
> Josh Berkus escribió:
>
>> Or is this just about whitespace and line breaks?
>
> If the docs are going to be rehauled, please ignore my whitespace
> comments.
I'm sure you'll find plenty to criticize in my version. ;-)
--
Josh Berkus
PostgreSQL
Josh Berkus escribió:
> Or is this just about whitespace and line breaks?
If the docs are going to be rehauled, please ignore my whitespace
comments.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hacke
On 01/28/2014 10:29 AM, Merlin Moncure wrote:
>> In addition to this, the JSON vs JSONB datatype page really needs
>> expansion and clarification.
>
> right: exactly. I'd be happy to help (such as I can) ...I wanted to
> see if jsonb to make it in on this 'fest (doc issues notwithstanding);
> it
On Tue, Jan 28, 2014 at 12:09 PM, Josh Berkus wrote:
> On 01/28/2014 09:58 AM, Merlin Moncure wrote:
>> yeah. note: I think the json documentation needs *major* overhaul. too
>> much is going in inside the function listings where there really
>> should be a big breakout discussing the "big picture
On 01/28/2014 09:58 AM, Merlin Moncure wrote:
> yeah. note: I think the json documentation needs *major* overhaul. too
> much is going in inside the function listings where there really
> should be a big breakout discussing the "big picture" of json/jsonb
> with examples of various use cases. I wa
On Tue, Jan 28, 2014 at 10:46 AM, Andrew Dunstan wrote:
>
> On 01/28/2014 11:29 AM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>>
>>> The problem is not the indexterm element, it's the space that might
>>> exist outside it. Are we using block level elements like inside
>>> entry elements anyw
On 01/28/2014 11:29 AM, Tom Lane wrote:
Andrew Dunstan writes:
The problem is not the indexterm element, it's the space that might
exist outside it. Are we using block level elements like inside
entry elements anywhere else?
Probably not, and I wonder why you're trying to. Whole paras insid
Andrew Dunstan writes:
> The problem is not the indexterm element, it's the space that might
> exist outside it. Are we using block level elements like inside
> entry elements anywhere else?
Probably not, and I wonder why you're trying to. Whole paras inside
a table entry (this is a table no?
On 01/28/2014 11:27 AM, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane wrote:
Practically every existing use of is freer than this in its
use of whitespace. It sounds to me like maybe you are trying to put the
inside something it shouldn't go inside of.
FWIW I was just talking about form
Alvaro Herrera writes:
> Tom Lane wrote:
>> Practically every existing use of is freer than this in its
>> use of whitespace. It sounds to me like maybe you are trying to put the
>> inside something it shouldn't go inside of.
> FWIW I was just talking about formatting of the SGML source so tha
Tom Lane wrote:
> Andrew Dunstan writes:
> > On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
> > +
> > + jsonb_each
> > + json_each(json)
> > + jsonb_each(jsonb)
> > +
> >> This SGML nesting is odd and hard to read. Please place opening tags in
> >> separate
On 01/28/2014 11:09 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
+
+ jsonb_each
+ json_each(json)
+ jsonb_each(jsonb)
+
This SGML nesting is odd and hard to read. Please place opening tags in
separate lines
Andrew Dunstan writes:
> On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
> +
> + jsonb_each
> + json_each(json)
> + jsonb_each(jsonb)
> +
>> This SGML nesting is odd and hard to read. Please place opening tags in
>> separate lines (or at least not immediatel
On 01/28/2014 10:50 AM, Alvaro Herrera wrote:
+
+ jsonb_each
+ json_each(json)
+ jsonb_each(jsonb)
+
This SGML nesting is odd and hard to read. Please place opening tags in
separate lines (or at least not immediately following a closing tag). I
am not
Andrew Dunstan wrote:
>
> +There are two JSON data types: json and jsonb.
> +Both accept identical sets of values as input. The difference is
> primarily
> +a matter of efficiency. The json data type stores an exact
> +copy of the the input text, and the processing functions
On 01/28/2014 09:38 AM, Merlin Moncure wrote:
On Mon, Jan 27, 2014 at 9:43 PM, Andrew Dunstan wrote:
On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
Here is the latest set of patches for nested hstore and jsonb.
Because it's so large I've broken this into two patches and compressed
them. The
> Looks like this review is against jsonb-5, not jsonb-6.
oh yep -- shoot, sorry for the noise.
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jan 27, 2014 at 9:43 PM, Andrew Dunstan wrote:
>
> On 01/26/2014 05:42 PM, Andrew Dunstan wrote:
>>
>>
>> Here is the latest set of patches for nested hstore and jsonb.
>>
>> Because it's so large I've broken this into two patches and compressed
>> them. The jsonb patch should work standal
401 - 431 of 431 matches
Mail list logo
