On Dec 5, 2012, at 11:51 AM, Andrew Dunstan wrote:
>> So I'm happy with this stuff, as long as it does not get in the way of
>> supporting indexing at some point in the future. I can’t wait to start using
>> it!
>
> I don't see why it should get in the way of anything like that. If anything,
On Wed, Dec 5, 2012 at 12:42 PM, David E. Wheeler wrote:
> On Dec 5, 2012, at 9:57 AM, Merlin Moncure wrote:
>
>> Indexing large documents for fancy querying is a niche case but also
>> quite complex. This isn't very well covered by xmlpath either btw --
>> I think for inspiration we should be l
On 12/05/2012 01:48 PM, David E. Wheeler wrote:
I'm sorry what I have offered isn't what you want, but plenty of other people
have told me it will go a long way meeting their needs.
*Sigh.* I guess I have not been clear.
The stuff you propose is *awesome*. I love it. The syntax with the chain
On 12/05/2012 01:49 PM, Josh Berkus wrote:
*) xmlpath/jsonpath do searching (and decomposition) but are very
clunky from sql perspective and probably absolutely nogo in terms if
GIST/GIN. postgres spiritually wants to do things via operators and
we should (if possible) at least consider that fi
On 2012-12-05 10:49:35 -0800, Josh Berkus wrote:
>
> >> *) xmlpath/jsonpath do searching (and decomposition) but are very
> >> clunky from sql perspective and probably absolutely nogo in terms if
> >> GIST/GIN. postgres spiritually wants to do things via operators and
> >> we should (if possible)
On Wed, Dec 5, 2012 at 12:49 PM, Josh Berkus wrote:
>
>>> *) xmlpath/jsonpath do searching (and decomposition) but are very
>>> clunky from sql perspective and probably absolutely nogo in terms if
>>> GIST/GIN. postgres spiritually wants to do things via operators and
>>> we should (if possible)
>> *) xmlpath/jsonpath do searching (and decomposition) but are very
>> clunky from sql perspective and probably absolutely nogo in terms if
>> GIST/GIN. postgres spiritually wants to do things via operators and
>> we should (if possible) at least consider that first
Why is it a nogo for GiST?
On Dec 5, 2012, at 10:04 AM, Andrew Dunstan wrote:
> Indexing tree-like data isn't at all easy. We don't index XML either. There
> has been discussion of this sort of indexing it in the past, and a couple of
> people have said they would work on it, but I have not seen a proposal or a
> single
On Dec 5, 2012, at 9:57 AM, Merlin Moncure wrote:
> Indexing large documents for fancy querying is a niche case but also
> quite complex. This isn't very well covered by xmlpath either btw --
> I think for inspiration we should be looking at hstore.
Agreed, although hstore, IIRC, does not suppo
On 12/05/2012 12:29 PM, David E. Wheeler wrote:
On Dec 5, 2012, at 9:21 AM, Andrew Dunstan wrote:
For sufficiently large columns, I expect I would want a GIN index to speed JSON
value extraction queries. Possible with this proposal?
Probably not.
That greatly reduces its utility for queryi
On Wed, Dec 5, 2012 at 11:14 AM, David E. Wheeler wrote:
> On Nov 28, 2012, at 4:10 PM, Merlin Moncure 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:
On Dec 5, 2012, at 9:21 AM, Andrew Dunstan wrote:
>> For sufficiently large columns, I expect I would want a GIN index to speed
>> JSON value extraction queries. Possible with this proposal?
>
> Probably not.
That greatly reduces its utility for querying, though not, of course, for using
it i
On 12/05/2012 12:14 PM, David E. Wheeler wrote:
On Nov 28, 2012, at 4:10 PM, Merlin Moncure 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. n
On 12/05/2012 12:11 PM, David E. Wheeler wrote:
On Dec 4, 2012, at 10:05 AM, Josh Berkus wrote:
json_get(json, variadic text) => json
Given that I already do the equivalent in Python, this would suit me
well. Not sure about other users ...
Well, given that sometimes you will have mixed
On Nov 28, 2012, at 4:10 PM, Merlin Moncure 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
On Dec 4, 2012, at 10:05 AM, Josh Berkus wrote:
>>json_get(json, variadic text) => json
>
> Given that I already do the equivalent in Python, this would suit me
> well. Not sure about other users ...
Well, given that sometimes you will have mixed arrays and objects, how would
you distingu
> Yes, you are, rather. It might be possible to do something like:
>
> json_get(json, variadic text) => json
Given that I already do the equivalent in Python, this would suit me
well. Not sure about other users ...
> as long as it doesn't involve any testing beyond field name / array
> in
On 12/03/2012 08:14 PM, Josh Berkus wrote:
Andrew,
What about doing:
json_get(json, json)
returns json
where parameter #2 is a path expressed as JSON? For example,
json_get(personal_profile, '[ {contact_info {phone numbers {cell phones}
} } ]')
... would return whatever was in that heirarch
Andrew,
What about doing:
json_get(json, json)
returns json
where parameter #2 is a path expressed as JSON? For example,
json_get(personal_profile, '[ {contact_info {phone numbers {cell phones}
} } ]')
... would return whatever was in that heirarchical object, in this case
an array of cell pho
On 11/30/2012 10:59 AM, Hannu Krosing wrote:
Btw, how does current json type handle code pages - is json always
utf-8 even when server encoding is not ?
if so then we could at least have a shortcut conversion of json to
utf8-text which can skip codepage changes.
IIRC json is stored and
On 11/30/2012 04:29 PM, Andrew Dunstan wrote:
On 11/30/2012 10:04 AM, Hannu Krosing wrote:
OK, so based on this discussion, I'm thinking of the following:
* keep the original functions and operators. json_keys is still
required for the case where the json is not flat.
* json_each(json)
On 11/30/2012 10:04 AM, Hannu Krosing wrote:
OK, so based on this discussion, I'm thinking of the following:
* keep the original functions and operators. json_keys is still
required for the case where the json is not flat.
* json_each(json) => setof (text, text)
errors if the json is
On 11/30/2012 03:38 PM, Andrew Dunstan wrote:
On 11/29/2012 06:34 PM, Merlin Moncure wrote:
On Thu, Nov 29, 2012 at 4:14 PM, Andrew Dunstan
wrote:
There are many things wrong with this. First, converting to hstore
so you
can call populate_record is quite horrible and ugly and inefficient.
An
On Fri, Nov 30, 2012 at 9:02 AM, Andrew Dunstan wrote:
>
> On 11/30/2012 09:51 AM, Merlin Moncure wrote:
>>
>>
>> Two questions:
>> 1) is it possible for these to work without a polymorphic object
>> passed through as hstore does (null::foo)?
>> select populate_record(anyelement, record, json)
>
On 11/30/2012 09:51 AM, Merlin Moncure wrote:
Two questions:
1) is it possible for these to work without a polymorphic object
passed through as hstore does (null::foo)?
select populate_record(anyelement, record, json)
I don't understand the question. The API I'm suggesting is exactly in
lin
On Fri, Nov 30, 2012 at 8:38 AM, Andrew Dunstan wrote:
> OK, so based on this discussion, I'm thinking of the following:
ok, this is looking awesome -- couple naming suggestions (see inline):
> * keep the original functions and operators. json_keys is still
>required for the case where the
On 11/29/2012 06:34 PM, Merlin Moncure wrote:
On Thu, Nov 29, 2012 at 4:14 PM, Andrew Dunstan wrote:
There are many things wrong with this. First, converting to hstore so you
can call populate_record is quite horrible and ugly and inefficient. And
it's dependent on having hstore loaded - you c
On Thu, Nov 29, 2012 at 4:14 PM, Andrew Dunstan wrote:
> There are many things wrong with this. First, converting to hstore so you
> can call populate_record is quite horrible and ugly and inefficient. And
> it's dependent on having hstore loaded - you can't have an hstore_to_jon in
> core because
On 11/29/2012 04:52 PM, Merlin Moncure wrote:
On Thu, Nov 29, 2012 at 1:19 PM, Andrew Dunstan wrote:
On 11/29/2012 01:06 PM, Merlin Moncure wrote:
so, just hashing out your proposal and making sure it's reasonable
analogous implementation of xpath. Sleeping on it, I say mostly, but
not quite
On Thu, Nov 29, 2012 at 1:19 PM, Andrew Dunstan wrote:
>
> On 11/29/2012 01:06 PM, Merlin Moncure wrote:
>>
>> so, just hashing out your proposal and making sure it's reasonable
>> analogous implementation of xpath. Sleeping on it, I say mostly, but
>> not quite. how about some changes for json_g
On 11/29/2012 01:06 PM, Merlin Moncure wrote:
so, just hashing out your proposal and making sure it's reasonable
analogous implementation of xpath. Sleeping on it, I say mostly, but
not quite. how about some changes for json_get:
1) return setof (key, value) in the style of jquery each().
2) w
On Thu, Nov 29, 2012 at 7:58 AM, Andrew Dunstan wrote:
> On 11/28/2012 08:16 PM, Hannu Krosing wrote:
>> You could even do a template-less row_from_json which returns a records
>> with all fields converted to
>> the JSON-encodable types and hope that the next conversions will be done
>> by postgre
On 11/28/2012 08:16 PM, Hannu Krosing wrote:
On 11/29/2012 02:07 AM, Hannu Krosing wrote:
On 11/29/2012 01:10 AM, Merlin Moncure wrote:
On Wed, Nov 28, 2012 at 2:44 PM, Andrew Dunstan
wrote:
...
*) have you considered something like
anyelement from_json(anyelement, json)
or
select ::some_
On 11/29/2012 02:07 AM, Hannu Krosing wrote:
On 11/29/2012 01:10 AM, Merlin Moncure wrote:
On Wed, Nov 28, 2012 at 2:44 PM, Andrew Dunstan
wrote:
...
*) have you considered something like
anyelement from_json(anyelement, json)
or
select ::some_type; (this may or many not be possible given
On 11/29/2012 01:10 AM, Merlin Moncure wrote:
On Wed, Nov 28, 2012 at 2:44 PM, Andrew Dunstan wrote:
...
*) have you considered something like
anyelement from_json(anyelement, json)
or
select ::some_type; (this may or many not be possible given our
casting mechanics; i don't know).
I have
On Wed, Nov 28, 2012 at 2:44 PM, Andrew Dunstan wrote:
> On 11/28/2012 02:08 PM, Merlin Moncure wrote:
>> *) ISTM your keytext operators are a reasonable replacement for a
>> hypothetical json_path. That said you're basically forcing json->sql
>> mapping through a highly iterative API, which I d
On 11/28/2012 03:44 PM, Andrew Dunstan wrote:
As for json_to_hstore, as I mentioned, the design is intended to
enable the easy constructyion of such transformations, although for
hstores anything except trivial json structure (i.e. an unnested
object) it might have unappealing results. But
On 11/28/2012 02:08 PM, Merlin Moncure wrote:
On Wed, Nov 28, 2012 at 11:04 AM, Andrew Dunstan wrote:
This is a proposal to create some basic functions to extract values from
json. The simple functions I envision would be:
* json_object_keys(json) => setof text
returns the set of dequot
On Wed, Nov 28, 2012 at 11:04 AM, Andrew Dunstan wrote:
>
> This is a proposal to create some basic functions to extract values from
> json. The simple functions I envision would be:
>
> * json_object_keys(json) => setof text
>returns the set of dequoted, unescaped keys of the object,
>er
39 matches
Mail list logo
