On Thu, Aug 11, 2016 at 10:42 AM, Ryan Pedela
wrote:
> On Thu, Aug 11, 2016 at 9:27 AM, Oleg Bartunov
> wrote:
>
>> On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela
>> wrote:
>> >
>> >
>>
>> > I would say that it is worth it to have a &qu
On Thu, Aug 11, 2016 at 9:27 AM, Oleg Bartunov wrote:
> On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela
> wrote:
> >
> >
>
> > I would say that it is worth it to have a "phrase slop" operator (Apache
> > Lucene terminology). Proximity search is extre
On Tue, Aug 9, 2016 at 12:59 PM, Ryan Pedela wrote:
>
>
> Thanks,
>
> Ryan Pedela
> Datalanche CEO, founder
> www.datalanche.com
>
> On Tue, Aug 9, 2016 at 11:58 AM, Tom Lane wrote:
>
>> Bruce Momjian writes:
>> > Does anyone know why the ph
Thanks,
Ryan Pedela
Datalanche CEO, founder
www.datalanche.com
On Tue, Aug 9, 2016 at 11:58 AM, Tom Lane wrote:
> Bruce Momjian writes:
> > Does anyone know why the phrase distance "<3>" was changed from "at most
> > three tokens away" to "ex
On Mon, May 23, 2016 at 11:14 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote:
>
>> Hi there,
>>
>> I noticed it was very easy to accidentally call the json_* form of JSON
>> manipulation functions with jsonb data as input.
Tika [1] for plain text extraction from HTML.
There are so many weird edge cases when parsing HTML that it is easier to
use something that is already mature than reinventing the wheel.
1. https://tika.apache.org/
Thanks,
Ryan Pedela
On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost wrote:
> * Ryan Pedela (rped...@datalanche.com) wrote:
> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni
> wrote:
> > > The default text representation of jsonb adds whitespace in between
> > > key/value pairs (
On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni wrote:
> Hi,
>
> The default text representation of jsonb adds whitespace in between
> key/value pairs (after the colon ":") and after successive properties
> (after the comma ","):
>
> postgres=# SELECT '{"b":2,"a":1}'::jsonb::text;
>text
On Mon, Sep 28, 2015 at 4:09 PM, Jim Nasby wrote:
> On 9/28/15 11:43 AM, Andres Freund wrote:
>
>> On 2015-09-28 09:41:18 -0700, David Fetter wrote:
>>
>>> Since you're convinced that this is an unqualified win, please put
>>> together a project plan for switching from our current system to
>>> G
list when an issue is created or
updated.
2. Replies to the email will automatically update the issue on Github.
3. Github is where most of the OSS activity happens now.
4. If Github goes away, so what? The core workflow never changes.
Thanks,
Ryan Pedela
On Thu, Jul 16, 2015 at 11:51 AM, Robert Haas wrote:
>
> I don't understand these issues in great technical depth, but if
> somebody is arguing that it's OK for PostgreSQL to be difficult to use
> for a certain category of user for several years until the next
> language rev becomes mainstream, th
On Wed, Jul 15, 2015 at 11:10 AM, Ryan Pedela
wrote:
> On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas
> wrote:
>
>> FWIW, I don't agree. If it's not easy to read the JSON that
>> PostgreSQL generates using JavaScript, then a lot of people are just
>> going
On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas wrote:
> FWIW, I don't agree. If it's not easy to read the JSON that
> PostgreSQL generates using JavaScript, then a lot of people are just
> going to give up on doing it, and IMO that would be sad. Telling
> people that they have to parse the JSON u
wise to add something to core just because one client
does stupid things with large numbers. In addition, ES7 is introducing
"value types" which will hopefully solve the large number problem in
Javascript.
The random whitespace issue is valid in my opinion and should be fixed.
Thanks,
Ryan Pedela
On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure wrote:
> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
> wrote:
> > Andrew Dunstan wrote:
> >>
> >> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
> >
> >> >Attached is a patch against master to generalize the JSON-producing
> >> >functions i
On Wed, May 20, 2015 at 12:34 PM, Andrew Dunstan
wrote:
>
> So Dmitry, at my suggestion, has come up with a way of doing that, by
> adding a parameter to jsonb_replace(). If this parameter is set to true (it
> defaults to false) and the key or array element pointed to by the last
> element of the
On Mon, May 18, 2015 at 12:24 PM, Josh Berkus wrote:
>
> On 05/18/2015 08:57 AM, Ryan Pedela wrote:
> > If not, deep concatenation would solve this problem, but I can also see
> > another solution. Use + for shallow concatenation since it really means
> > "add elemen
On Mon, May 18, 2015 at 8:41 AM, Ryan Pedela wrote:
> On Sun, May 17, 2015 at 9:41 PM, Josh Berkus wrote:
>
> Is there a particular reason why "+" makes more sense as "shallow
>> concatination" and "||" makes more sense as "deep concati
abase use case is being able to delete or replace/update a
specific, nested path in the JSON object. It looks like that is possible
with the minus operator and jsonb_replace(). This is great, however it took
me awhile to figure out the path syntax. I think adding a paragraph to the
docs explaining the path syntax would help.
Ryan Pedela
On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera
wrote:
>
>
> * Should we prohibit DDL from within event triggers?
>
Please don't prohibit DDL unless there is a really, really good reason to
do so. I have several use cases in mind for event triggers, but they are
only useful if I can perform DDL.
ort in event triggers is the
upcoming feature I am most excited about, and I am happy to see progress.
Thanks,
Ryan Pedela
If PL/Javascript is a serious consideration, how will int64 and numeric be
handled?
Thanks,
Ryan Pedela
Datalanche CEO, co-founder
www.datalanche.com
rped...@datalanche.com
513-571-6837
On Tue, Sep 2, 2014 at 6:38 AM, Andrew Dunstan wrote:
>
> On 09/02/2014 05:44 AM, Álvaro Hernández T
such as:
// applies a JSON Patch
json_patch_apply(json, patch)
// diffs two JSON objects and produces a JSON Patch
json_patch_diff(json a, json b)
Thanks,
Ryan Pedela
23 matches
Mail list logo