From: | Kevin Wooten <kdubb(at)me(dot)com> |
---|---|
To: | Dave Cramer <davecramer(at)gmail(dot)com> |
Cc: | List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL gaps wrt to java, and jdbc |
Date: | 2015-07-07 18:31:54 |
Message-ID: | 80FEC5E5-DD36-46F4-A510-31E08415FBB1@me.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
By “streaming a column” I assume you mean large bytea columns? If so, I say… hell yes.
Also,..
== Binary type coercion ==
The biggest impediment I’ve run into is the fact that PG will not attempt coercion on binary types. If you specify a binary type in the protocol, that’s the final word. A better system would be to have PG perform the same coercion it does for text types and then send the results back with coerced types, in binary; finally falling back to text when binary cannot be produced. This would solve almost every issue we have had to work around in the “ng” driver.
== Unbound binary results ==
Being able to send a query, without the parse & bind step, that returns binary results.
== Better cursor support ==
Providing capabilities that better match JDBC. PG is pretty close but a few cases make cursors not work as expected a lot of the time.
I could probably come up with a bunch more but these are the big ones that jump out at me.
I have a couple solutions (with no idea how to implement them)...
For "binary type coercion” & “unbound binary results” a simple setting flag telling PG that we basically know how to handle all the binary types would suffice. In this flag was set PG could just start returning stuff in the fashion we want and it would helpfully “just work”.
For streaming it seems a sub mode, similar to the copy protocol, that doesn’t force us out of the transaction but can send us multiple packets would really help. Although I know there are many factors at work on the server that I definitely don’t understand.
> On Jul 6, 2015, at 5:14 AM, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
>
> I have been actively maintaining the driver off and on since 1999 or so. Recently we have had a flurry of activity and one of the things I noticed was the surprise that PostgreSQL didn't support X or did Y in some unexpected way. Sometimes we are a bit too complacent, and accept things the way they are.
>
> I am wondering what could the server do better that would help JDBC?
>
> Obviously streaming a column is one. Possibly rowid's. Anything else ?
>
>
> Dave Cramer
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-07-07 19:46:48 | Re: PostgreSQL gaps wrt to java, and jdbc |
Previous Message | Dave Cramer | 2015-07-07 17:54:03 | Re: PostgreSQL gaps wrt to java, and jdbc |