Re: JDBC behaviour
| От | Craig Ringer |
|---|---|
| Тема | Re: JDBC behaviour |
| Дата | |
| Msg-id | CAMsr+YH3NHZ__xSxWfVH4neGa6w8nLRuLLRG8kqXt9bgE1eEBA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [JDBC] JDBC behaviour (Sridhar N Bamandlapally <sridhar.bn1@gmail.com>) |
| Ответы |
Re: [HACKERS] JDBC behaviour
(Robert Haas <robertmhaas@gmail.com>)
|
| Список | pgsql-hackers |
On 20 February 2016 at 12:40, Sridhar N Bamandlapally <sridhar.bn1@gmail.com> wrote:
Hi AllI 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.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Filip RembiałkowskiДата:
Сообщение: Re: proposal: make NOTIFY list de-duplication optional