Re: SQLJSON - Mailing list pgsql-jdbc
| From | Markus KARG |
|---|---|
| Subject | Re: SQLJSON |
| Date | |
| Msg-id | 002401d0b1b4$f8941bb0$e9bc5310$@eu Whole thread Raw |
| In response to | Re: SQLJSON (Dave Cramer <pg@fastcrypt.com>) |
| Responses |
Re: SQLJSON
(Dave Cramer <pg@fastcrypt.com>)
|
| List | pgsql-jdbc |
Wouldn't it be more clever to ask the pgjdbc *users* what *they* expect to get instead of solely relying upon us three? As the discussion turned out, we have fundamentally diverse opinions, and I doubt that we will do it any right if we just do "something" simply for the benefit of writing "JSON support" on our driver.
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer
Sent: Sonntag, 28. Juni 2015 15:56
To: Álvaro Hernández Tortosa
Cc: List
Subject: Re: [JDBC] SQLJSON
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.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On 28 June 2015 at 06:00, Álvaro Hernández Tortosa <aht@8kdata.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@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Álvaro Hernández
Tortosa
Sent: Sonntag, 28. Juni 2015 11:44
To: pgsql-jdbc@postgresql.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
pgsql-jdbc by date: