Re: json accessors

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: json accessors
Date: 2012-12-05 17:14:52
Message-ID: 343A16DA-0C4B-41F3-8E18-51FBA5A29E48@justatheory.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Nov 28, 2012, at 4:10 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:

>> Yes, it's iterative. And for deeply nested json it might be somewhat
>> inefficient, although the parser is pretty fast AFAICT. But it's a start.
>
> not completely buying that: see comments below. not supporting xpath
> style decompositions seems wrong to me. IOW, json_get should be set
> returning (perhaps via wild cards in the keytext) or we need
> json_each.

The problem I see with the current proposal is that this limitation, it seems to me, would prevent the ability to index nested keys. If you're essentially composing and decomposing JSON values as you drill down, the intermediate JSON values between the original one and the final return value can't be indexed, can they?

For sufficiently large columns, I expect I would want a GIN index to speed JSON value extraction queries. Possible with this proposal?

Best,

David

PS: SOrry for the delayed replies, digging my way out of a couple weeks of back posts…

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-12-05 17:17:20 Re: PITR potentially broken in 9.2
Previous Message Dimitri Fontaine 2012-12-05 17:14:10 Re: ALTER TABLE ... NOREWRITE option