Re: JDBC behaviour

On 20 February 2016 at 12:40, Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)com
> wrote:

> Hi All
>
> I understand your point,
>
> may be I didn't understand everyone or everyone didn't understand me
>

Sounds like it.

> one feature of PostgreSQL is implemented into another feature of Java ( i
> say subject PostgreSQL::autocommit Vs JDBC::setAutoCommit ),
>

There's no JDBC::setAutoCommit . If you're going to discuss behavour please
be very specific. Do you mean java.sql.Connection.setAutoCommit(boolean) ?

i.e PostgreSQL::"set autocommit to FALSE" is implemented as
> JDBC::"BEGIN-<statements>-END"
>

This does not make any sense.

All setAutoCommit(false) does is tells the drive to begin a transaction
when the next statement is run and not commit it automatically. It doesn't
actually do anything its self.

It certainly doesn't run any block of statements.

By the way, "END" is kind of confusing. I presume you mean "COMMIT", which
is the more usual way to say that? PostgreSQL does support "END" as an
alias for COMMIT, but it's a pretty weird way to write it.

If you are going to discuss the behaviour of the driver please be specific
and accurate. Use the actual commands/queries/functions that the driver
uses or the specification describes, don't make up vague descriptions that
don't reflect what actually happens.

> currently PostgreSQL::"set autocommit to FALSE ( not supported )
>

This also does not make any sense.

PgJDBC does support turning autocommit off. So I don't know in what way
it's "not supported".

> say in future, if PostgreSQL come with proper fix/support for "set
> autocommit to FALSE"
>

It already supports it.

The only behaviour change that might be contemplated is a change for spec
compliance where we delay commit of a statement in autocommit mode until
the ResultSet and/or Statement are closed. Right now we commit immediately,
which is what most users expect, but apparently conflicts with how the JDBC
spec expects things to work when it comes to the duration of locks being
held etc.

There was a prior discussion thread on this.

That's a (fairly) minor detail, though it could have a significant impact
on apps. It does not change the fact that PgJDBC supports autocommit on or
off and will continue to do so.

> then will JDBC-team change the to code to JDBC::"set autocommit to FALSE"
> ?, then what about existing behaviors dependency applications ?
>

What behavour exactly are you talking about changing?

It already supports turning autocommit off.

> this could have handled in different way in blogs saying to add
> "BEGIN-END" from JDBC-connection-query with warning
>

I don't understand what you're trying to say here.

> simple, if PostgreSQL DB is not support then same with PostgreSQL JDBC
> too, if still JDBC want to support then need to support with expected
> behavior way only, how come other feature is added to this ?
>

I don't understand this.

> 1. "every/entire application developers expected behavior are matching,
> only PostgreSQL::JDBC-team is not in sync"
>

Please provide a complete, compileable, self-contained example
demonstrating behaviour that causes a failure or problem in PgJDBC but
works correctly with at least most of:

- MS SQL
- Oracle
- DB2
- Sybase
- MySQL

including test run output demonstrating the details of what exactly the
behaviour of each other implementation is.

Please show where in the JDBC specification the behaviour is described.

> 2. "every organisation want there applications to be multi-database
> compatible, only PostgreSQL::JDBC-team <don't know what to say>"
>

Well, nobody's truly "multi-database compatible" because the SQL spec is in
some areas vague and hard to interpret. Every DBMS has extensions and
quirks. Oracle thinks that "" = NULL is TRUE, for example. JDBC
implementations vary too.

Of course it's desirable to be more consistent and compatible where that's
practical, but you need to actually show clear evidence that other DBMSes
all do it one way and we do it a different way. With real, detailed,
complete code examples and test output.

Hand-waving about how we're doing it wrong won't get you anywhere.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services