Re: problem with precendence order in JSONB merge operator

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Peter Krauss <ppkrauss(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: problem with precendence order in JSONB merge operator
Date: 2016-03-23 00:52:23
Message-ID: CAKFQuwb6GXMWu95_fSbxjHi=qwqrcUCpqTG-Qr-KL_mAM6H4Mw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Please don't top-post.

On Tuesday, March 22, 2016, Peter Krauss <ppkrauss(at)gmail(dot)com> wrote:

> Subjective notes to contextualize (try to explain on bad-English) my
> "precedence order" and JSONB visions:
>
> JSON datatype is perfect as workaround, and for many simple and less
> exigent applications.
> JSONB is the "first class" datatype for user community, we expected years
> (!) for it ... Need some "first class" and friendly behaviour.
>
> In this context JSONB is not "any other" datatype, it is the bridge
> between relational data and flexible data...
> It is the Holy Grail and the Rosetta Stone :-)
>
> I think JSONB operators need some more attention, in semantic and
> usability contexts. If you want to add some friendliness and
> orthogonality in JSONB operators, will be natural to see -> operator as a
> kind of object-oriented *path* operator...
> By other hand, of course, you can do the simplest to implement JSONB...
> But you do a lot
> <http://www.postgresql.org/docs/9.5/static/functions-json.html> (!), it
> was not easy to arrive here, and need only a little bit more to reach
> perfection ;-)
>
>
You are welcome to supply a patch for this particular "little bit" - but I
suspect you will find it quite disruptive to backward compatibility and
general system internals if you attempt to do so. But maybe not.

Any change you make in this area will effect every usage of that operator
whether part of core or end-user defined. We have baggage that limits
our ability to be perfect.

So while I'll agree with your premise I don't see (really, don't care to
look for) a way to make your desire a reality. But you and smarter people
than I are welcome to dive into the code and see if you can come up with
something that works.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-03-23 00:52:39 Re: WAL logging problem in 9.4.3?
Previous Message Tom Lane 2016-03-23 00:51:38 Re: Missing rows with index scan when collation is not "C" (PostgreSQL 9.5)