Re: SQLJSON

On 28/06/15 15:56, Dave Cramer wrote:
> So I think we should support JSR 353 at the very least Whether we
> extend the result set or not we can at a minimum return a JsonValue
> from getObject
>
> I agree with Alvaro, 99% of the users would just like a JsonValue
> returned. It would be nice if we could design this so more advanced
> users could plug in their parser of choice.

Yes, at least to have a JsonValue would be a really nice addition.

To plug your parser, JSR 353 follows Java's standard SPI and is as
simple as write the fqcn of the driver implementation to
META-INF/services/javax.json.spi.JsonProvider. So rather than asking
everybody to do that, it would be even nicer to embed the JSR353
Reference Implementation (a mere 64Kb) and let advanced users override
the parser by writing the services file. I know that adding external
dependencies is not everybody's favorite idea here, but I really believe
it definitely help (most) users and would allow us to ship a driver that
would work out-of-the-box with JSON.

Regards,

Álvaro

--
Álvaro Hernández Tortosa

-----------
8Kdata

>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
> On 28 June 2015 at 06:00, Álvaro Hernández Tortosa <aht(at)8kdata(dot)com
> <mailto:aht(at)8kdata(dot)com>> wrote:
>
>
> On 28/06/15 11:51, Markus KARG wrote:
>
> It is not *us* who let the JSON users down, it is the
> PostgreSQL protocol
> guys who did not add any useful support for JSON. A driver is
> not a
> compensation for missing product features, it is just a thin
> wrapper around
> the base product's features.
>
> To have proper JSON support at the protocol level (something
> which I'd love to have) only translates to more performance, no
> more functionality. So is a nice-to-have, not a must-to-have (as
> is supporting PostgreSQL's json data types).
>
>
> I mean, what happens if the application shall work with a
> different product?
> If you rely on non-JDBC-features, you're screwed. So a profession
> application using JSON should ALWAYS come with JSR 253 anyways.
>
> We have had to extend JDBC in several ways in the past. We
> should do it again, now, in the best possible manner (getObject,
> PGResultSet, whatever). And then, if JDBC adds support in the
> future, retrofit into it. But not wait until then, because we
> don't even know if that would even happen.
>
> Cheers,
>
>
> Álvaro
>
>
> --
> Álvaro Hernández Tortosa
>
>
> -----------
> 8Kdata
>
>
>
>
> -----Original Message-----
> From: pgsql-jdbc-owner(at)postgresql(dot)org
> <mailto:pgsql-jdbc-owner(at)postgresql(dot)org>
> [mailto:pgsql-jdbc-owner(at)postgresql(dot)org
> <mailto:pgsql-jdbc-owner(at)postgresql(dot)org>] On Behalf Of Álvaro
> Hernández
> Tortosa
> Sent: Sonntag, 28. Juni 2015 11:44
> To: pgsql-jdbc(at)postgresql(dot)org <mailto:pgsql-jdbc(at)postgresql(dot)org>
> Subject: Re: [JDBC] SQLJSON
>
>
> On 28/06/15 11:17, Markus KARG wrote:
>
> I do not see the benefit of that effort, as getting JSON
> as a LONG VARCHAR
> and then parsing it on behalf of the application is pretty
> simple and
> straightforward. My vote would be to not do anything until
> JDBC 4.3 of
>
> JDBC
>
> 5.0 provides a standard API for dealing with JSON inside
> of the driver or
>
> at
>
> least PostgreSQL 9.5 or PostgreSQL 10 provides a streaming
> protocol for
>
> JSON
>
> and / or XML.
>
> Don't do anything?
>
> And let Java PostgreSQL users down, without a (driver,
> supported)
> means of getting JSON out of their database? So we make the
> "marketing"
> that 9.4 is all about jsonb and the NoSQL replacement yet you
> cannot do
> JSON with Java?
>
> Really?
>
> User's don't care about extreme performance. Users care
> about easy
> of use and decent set of features. Adding JSON support, even
> thought
> it's not the most performant one is something we should be
> doing as
> quickly as possible.
>
> Regards,
>
> Álvaro
>
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org
> <mailto:pgsql-jdbc(at)postgresql(dot)org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>