Re: SQLJSON

>  so that you don't need to parse it manually, which is a pain for many users

A) Can you please list pain points in literal?
I think we've already agreed that "having readme" is good enough so
even newbies can add dependencies.
What are the other pain points except "need to add a couple of jars if
json is needed"?

Frankly speaking, I find current "different jdbc version jars" even
more confusing than "if you want json, add pgjdbc-json dependency".

> so that you don't need to parse it manually,

B) That does not work that way.
Can you suggest a piece of "user code" you have in mind?

Let me predict it a bit:
1) It processes resultset
2) Fetches "JsonValue"
3) Passes to a business-logic class

We can stop here.
"business logic class" from #3 will definitely have "JsonValue"
classes in its method signatures.
In other words, it would require to have "javax.json" API in the class
path to compile.

Then I would love to know how is the user addressing that without
adding "javax.json" API dependency to her build system of choice.

The same business logic should be unit-tested (without DB), shouldn't it?
That results in "it should be testable without pgdjbc dependency".

C) If we continue creating bundles here and there (not sure what is
"non offensive" wording here), the number of possible bundles would
explode exponentially. jdbc driver is not an application for end-user,
so I do not see much reason why it should "bundle optional
dependencies without shading them".

For instance, if we decide to use objectweb.asm bytecode transformer,
it would be perfectly fine to shade it into org.postgresql.asm...
package, so it is not exposed to public.

However, with javax.json you cannot do package renaming since it would
make no sense.

D) Theoretically, we could represent json as java.util.Map /
java.util.List by embedding and repackaging some json implementation,
however I am not sure if that makes much sense provided JSR353 defines
proper interfaces.

Vladimir