Thread: JDBC 4 Compliance

The 9.2-1002 JDBC 4 driver version does not appear to provide the
IS_GENERATEDCOLUMN column in the ResultSet returned by

ResultSet DatabaseMetaData.getColumns(String catalog,
                   String schemaPattern,
                   String tableNamePattern,
                   String columnNamePattern)

It does not appear that method in the Java Docs defines such a
column, IS_GENERATEDCOLUMN, to be returned. The code also does
not indicated any such column. IS_AUTOINCREMENT maybe? Can you
please clarify?

danap.

REBruchs wrote:
> The 9.2-1002 JDBC 4 driver version does not appear to provide the
> IS_GENERATEDCOLUMN column in the ResultSet returned by
>
> ResultSet DatabaseMetaData.getColumns(String catalog,
>                     String schemaPattern,
>                     String tableNamePattern,
>                     String columnNamePattern)
>
>
>

Please see the Oracle JAVA SE API documentation at
http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html

Refer to method getColumns(), column 24 IS_GENERATEDCOLUMN

Thanks for looking into this.

-----Original Message-----
From: Kevin Wooten [mailto:kdubb@me.com]
Sent: Saturday, June 22, 2013 2:13 PM
To: dmp
Cc: REBruchs; PostgreSQL JDBC
Subject: Re: [JDBC] JDBC 4 Compliance

This column is defined in JDBC 4.1 which is not supported by the driver.

It is supported in my separate implementation of the driver. pgjdbc-ng
<https://github.com/kdubb/pgjdbc-ng>


On Jun 22, 2013, at 9:49 AM, dmp <danap@ttc-cmc.net> wrote:


    It does not appear that method in the Java Docs defines such a
    column, IS_GENERATEDCOLUMN, to be returned. The code also does
    not indicated any such column. IS_AUTOINCREMENT maybe? Can you
    please clarify?

    danap.

    REBruchs wrote:


        The 9.2-1002 JDBC 4 driver version does not appear to
provide the
        IS_GENERATEDCOLUMN column in the ResultSet returned by

        ResultSet DatabaseMetaData.getColumns(String catalog,
                           String schemaPattern,
                           String tableNamePattern,
                           String columnNamePattern)







    --
    Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
    To make changes to your subscription:
    http://www.postgresql.org/mailpref/pgsql-jdbc

Yes. You are referencing the Java 7 documentation which, as I referenced previously, is JDBC 4.1; the mainstream driver
doesnot currently only covers JDBC 4. 

If you look at the same Java 6 docs (http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html), which is
JDBC4, you'll see that there is no 24th column. 


On Jun 22, 2013, at 1:50 PM, REBruchs <REBruchs@cfl.rr.com> wrote:

> Please see the Oracle JAVA SE API documentation at
> http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>
> Refer to method getColumns(), column 24 IS_GENERATEDCOLUMN
>
> Thanks for looking into this.
>
> -----Original Message-----
> From: Kevin Wooten [mailto:kdubb@me.com]
> Sent: Saturday, June 22, 2013 2:13 PM
> To: dmp
> Cc: REBruchs; PostgreSQL JDBC
> Subject: Re: [JDBC] JDBC 4 Compliance
>
> This column is defined in JDBC 4.1 which is not supported by the driver.
>
> It is supported in my separate implementation of the driver. pgjdbc-ng
> <https://github.com/kdubb/pgjdbc-ng>
>
>
> On Jun 22, 2013, at 9:49 AM, dmp <danap@ttc-cmc.net> wrote:
>
>
>     It does not appear that method in the Java Docs defines such a
>     column, IS_GENERATEDCOLUMN, to be returned. The code also does
>     not indicated any such column. IS_AUTOINCREMENT maybe? Can you
>     please clarify?
>
>     danap.
>
>     REBruchs wrote:
>
>
>         The 9.2-1002 JDBC 4 driver version does not appear to
> provide the
>         IS_GENERATEDCOLUMN column in the ResultSet returned by
>
>         ResultSet DatabaseMetaData.getColumns(String catalog,
>                            String schemaPattern,
>                            String tableNamePattern,
>                            String columnNamePattern)
>
>
>
>
>
>
>
>     --
>     Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

I cannot speak to when the main driver will add JDBC 4.1 features.  I can say that my alternate driver, the project I
linkedto previously, does adhere to JDBC 4.1 for the features it implements.  You may want to try it out and see if it
worksfor you as its only 2 glaring JDBC feature omissions are updatable result-sets and  call statements. 

On Jun 22, 2013, at 7:34 PM, REBruchs <REBruchs@cfl.rr.com> wrote:

> Kevin,
>
> Thanks for pointing that out.
> I noticed the same also. You are also probably aware of the recent turmoil
> regarding the security problems with Java and Oracle's efforts to push at
> least Java 7u21 and preferably Java 7u25 to the masses.
>
> Oracle has stated that Java 6u45 has been archived and recommends Java 7.
>
> My original email was not sent as a complaint, but more as an inquiry as to
> when the PostgreSQL JDBC4 driver (that more closely adheres to the Java 7
> JDBC API) might be made available to the development community.
>
> I am a long time PostgreSQL and PostgreSQL JDBC driver user and have been
> quite happy with PostgreSQL for quite some time now.
>
> Thank you for your timely responses, and I applaud your efforts and the
> efforts of other JDBC driver team members in continuing to provide
> developers of Java/PostgreSQL applications a quality JDBC driver.
>
> Best regards,
>
> Robert Bruchs
>
> -----Original Message-----
> From: Kevin Wooten [mailto:kdubb@me.com]
> Sent: Saturday, June 22, 2013 6:19 PM
> To: REBruchs
> Cc: 'dmp'; 'PostgreSQL JDBC'
> Subject: Re: [JDBC] JDBC 4 Compliance
>
> Yes. You are referencing the Java 7 documentation which, as I referenced
> previously, is JDBC 4.1; the mainstream driver does not currently only
> covers JDBC 4.
>
> If you look at the same Java 6 docs
> (http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html),
> which is JDBC 4, you'll see that there is no 24th column.
>
>
> On Jun 22, 2013, at 1:50 PM, REBruchs <REBruchs@cfl.rr.com> wrote:
>
>> Please see the Oracle JAVA SE API documentation at
>> http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>>
>> Refer to method getColumns(), column 24 IS_GENERATEDCOLUMN
>>
>> Thanks for looking into this.
>>
>> -----Original Message-----
>> From: Kevin Wooten [mailto:kdubb@me.com]
>> Sent: Saturday, June 22, 2013 2:13 PM
>> To: dmp
>> Cc: REBruchs; PostgreSQL JDBC
>> Subject: Re: [JDBC] JDBC 4 Compliance
>>
>> This column is defined in JDBC 4.1 which is not supported by the driver.
>>
>> It is supported in my separate implementation of the driver. pgjdbc-ng
>> <https://github.com/kdubb/pgjdbc-ng>
>>
>>
>> On Jun 22, 2013, at 9:49 AM, dmp <danap@ttc-cmc.net> wrote:
>>
>>
>>     It does not appear that method in the Java Docs defines such a
>>     column, IS_GENERATEDCOLUMN, to be returned. The code also does
>>     not indicated any such column. IS_AUTOINCREMENT maybe? Can you
>>     please clarify?
>>
>>     danap.
>>
>>     REBruchs wrote:
>>
>>
>>         The 9.2-1002 JDBC 4 driver version does not appear to
>> provide the
>>         IS_GENERATEDCOLUMN column in the ResultSet returned by
>>
>>         ResultSet DatabaseMetaData.getColumns(String catalog,
>>                            String schemaPattern,
>>                            String tableNamePattern,
>>                            String columnNamePattern)
>>
>>
>>
>>
>>
>>
>>
>>     --
>>     Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>>     To make changes to your subscription:
>>     http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>>
>>
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>

Kevin,

Thanks for pointing that out.
I noticed the same also. You are also probably aware of the recent turmoil
regarding the security problems with Java and Oracle's efforts to push at
least Java 7u21 and preferably Java 7u25 to the masses.

Oracle has stated that Java 6u45 has been archived and recommends Java 7.

My original email was not sent as a complaint, but more as an inquiry as to
when the PostgreSQL JDBC4 driver (that more closely adheres to the Java 7
JDBC API) might be made available to the development community.

I am a long time PostgreSQL and PostgreSQL JDBC driver user and have been
quite happy with PostgreSQL for quite some time now.

Thank you for your timely responses, and I applaud your efforts and the
efforts of other JDBC driver team members in continuing to provide
developers of Java/PostgreSQL applications a quality JDBC driver.

Best regards,

Robert Bruchs

-----Original Message-----
From: Kevin Wooten [mailto:kdubb@me.com]
Sent: Saturday, June 22, 2013 6:19 PM
To: REBruchs
Cc: 'dmp'; 'PostgreSQL JDBC'
Subject: Re: [JDBC] JDBC 4 Compliance

Yes. You are referencing the Java 7 documentation which, as I referenced
previously, is JDBC 4.1; the mainstream driver does not currently only
covers JDBC 4.

If you look at the same Java 6 docs
(http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html),
which is JDBC 4, you'll see that there is no 24th column.


On Jun 22, 2013, at 1:50 PM, REBruchs <REBruchs@cfl.rr.com> wrote:

> Please see the Oracle JAVA SE API documentation at
> http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>
> Refer to method getColumns(), column 24 IS_GENERATEDCOLUMN
>
> Thanks for looking into this.
>
> -----Original Message-----
> From: Kevin Wooten [mailto:kdubb@me.com]
> Sent: Saturday, June 22, 2013 2:13 PM
> To: dmp
> Cc: REBruchs; PostgreSQL JDBC
> Subject: Re: [JDBC] JDBC 4 Compliance
>
> This column is defined in JDBC 4.1 which is not supported by the driver.
>
> It is supported in my separate implementation of the driver. pgjdbc-ng
> <https://github.com/kdubb/pgjdbc-ng>
>
>
> On Jun 22, 2013, at 9:49 AM, dmp <danap@ttc-cmc.net> wrote:
>
>
>     It does not appear that method in the Java Docs defines such a
>     column, IS_GENERATEDCOLUMN, to be returned. The code also does
>     not indicated any such column. IS_AUTOINCREMENT maybe? Can you
>     please clarify?
>
>     danap.
>
>     REBruchs wrote:
>
>
>         The 9.2-1002 JDBC 4 driver version does not appear to
> provide the
>         IS_GENERATEDCOLUMN column in the ResultSet returned by
>
>         ResultSet DatabaseMetaData.getColumns(String catalog,
>                            String schemaPattern,
>                            String tableNamePattern,
>                            String columnNamePattern)
>
>
>
>
>
>
>
>     --
>     Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

As we have all seen Oracle is pushing forward with the releases of Java. I
myself in the last few months have received notices from Oracle of Java 6
no longer supported, updates to fix security issues with Java 7, and now a
push for Java 8. While a majority of developers are I think comfortable
with Java 6 and argued that it has only been out a few years that will not
last given the accelerated hyper release activities of projects. Look at
Firefox.

The issue here I think is the pushing forward of the pgJDBC, it feels like
it's in maintenance mode. pgJDBC is the official supported driver for PostgreSQL
right?

Now though it appears to have at least one fork, if not multiple. What the
project should be trying to do is bring in new developers like Kevin to work
on the existing pgJDBC driver to bring it in to compliance with the new Java
releases.

I don't know how the pgJDBC project is going to accomplish this, but if
someone could indicated to me how Java Version 7, JDBC4-(4)/JDBC4.1-(4.1),
is referenced by in the code I could try to at least resolve this one issue
by reviewing the existing code and Kevin's to create a patch. Perhaps from
this review IS_GENERATEDCOLUMN could be at least defined if not already so.

danap.
Dana M. Proctor
MyJSQLView Project Manager

Dave Cramer wrote:
> Robert,
>
> What are you looking for here. I'm not sure that the protocol provides
> the information to determine if a column is generated. Generated could
> mean many things....
>
> If on the other hand you just want adherence to the spec and adding the
> column in with a "" as undetermined that seems trivial
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Sat, Jun 22, 2013 at 10:53 PM, Kevin Wooten <kdubb@me.com
> <mailto:kdubb@me.com>> wrote:
>
>     I cannot speak to when the main driver will add JDBC 4.1 features.
>       I can say that my alternate driver, the project I linked to
>     previously, does adhere to JDBC 4.1 for the features it implements.
>       You may want to try it out and see if it works for you as its only
>     2 glaring JDBC feature omissions are updatable result-sets and  call
>     statements.
>
>     On Jun 22, 2013, at 7:34 PM, REBruchs <REBruchs@cfl.rr.com
>     <mailto:REBruchs@cfl.rr.com>> wrote:
>
>      > Kevin,
>      >
>      > Thanks for pointing that out.
>      > I noticed the same also. You are also probably aware of the
>     recent turmoil
>      > regarding the security problems with Java and Oracle's efforts to
>     push at
>      > least Java 7u21 and preferably Java 7u25 to the masses.
>      >
>      > Oracle has stated that Java 6u45 has been archived and recommends
>     Java 7.
>      >
>      > My original email was not sent as a complaint, but more as an
>     inquiry as to
>      > when the PostgreSQL JDBC4 driver (that more closely adheres to
>     the Java 7
>      > JDBC API) might be made available to the development community.
>      >
>      > I am a long time PostgreSQL and PostgreSQL JDBC driver user and
>     have been
>      > quite happy with PostgreSQL for quite some time now.
>      >
>      > Thank you for your timely responses, and I applaud your efforts
>     and the
>      > efforts of other JDBC driver team members in continuing to provide
>      > developers of Java/PostgreSQL applications a quality JDBC driver.
>      >
>      > Best regards,
>      >
>      > Robert Bruchs
>      >
>      > -----Original Message-----
>      > From: Kevin Wooten [mailto:kdubb@me.com <mailto:kdubb@me.com>]
>      > Sent: Saturday, June 22, 2013 6:19 PM
>      > To: REBruchs
>      > Cc: 'dmp'; 'PostgreSQL JDBC'
>      > Subject: Re: [JDBC] JDBC 4 Compliance
>      >
>      > Yes. You are referencing the Java 7 documentation which, as I
>     referenced
>      > previously, is JDBC 4.1; the mainstream driver does not currently
>     only
>      > covers JDBC 4.
>      >
>      > If you look at the same Java 6 docs
>      >
>     (http://docs.oracle.com/javase/6/docs/api/java/sql/DatabaseMetaData.html),
>      > which is JDBC 4, you'll see that there is no 24th column.
>      >
>      >
>      > On Jun 22, 2013, at 1:50 PM, REBruchs <REBruchs@cfl.rr.com
>     <mailto:REBruchs@cfl.rr.com>> wrote:
>      >
>      >> Please see the Oracle JAVA SE API documentation at
>      >>
>     http://docs.oracle.com/javase/7/docs/api/java/sql/DatabaseMetaData.html
>      >>
>      >> Refer to method getColumns(), column 24 IS_GENERATEDCOLUMN
>      >>
>      >> Thanks for looking into this.
>      >>
>      >> -----Original Message-----
>      >> From: Kevin Wooten [mailto:kdubb@me.com <mailto:kdubb@me.com>]
>      >> Sent: Saturday, June 22, 2013 2:13 PM
>      >> To: dmp
>      >> Cc: REBruchs; PostgreSQL JDBC
>      >> Subject: Re: [JDBC] JDBC 4 Compliance
>      >>
>      >> This column is defined in JDBC 4.1 which is not supported by the
>     driver.
>      >>
>      >> It is supported in my separate implementation of the driver.
>     pgjdbc-ng
>      >> <https://github.com/kdubb/pgjdbc-ng>
>      >>
>      >>
>      >> On Jun 22, 2013, at 9:49 AM, dmp <danap@ttc-cmc.net
>     <mailto:danap@ttc-cmc.net>> wrote:
>      >>
>      >>
>      >>      It does not appear that method in the Java Docs defines such a
>      >>      column, IS_GENERATEDCOLUMN, to be returned. The code also does
>      >>      not indicated any such column. IS_AUTOINCREMENT maybe? Can you
>      >>      please clarify?
>      >>
>      >>      danap.
>      >>
>      >>      REBruchs wrote:
>      >>
>      >>
>      >>              The 9.2-1002 JDBC 4 driver version does not appear to
>      >> provide the
>      >>              IS_GENERATEDCOLUMN column in the ResultSet returned by
>      >>
>      >>              ResultSet DatabaseMetaData.getColumns(String catalog,
>      >>                                 String schemaPattern,
>      >>                                 String tableNamePattern,
>      >>                                 String columnNamePattern)
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>      --
>      >>      Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org
>     <mailto:pgsql-jdbc@postgresql.org>)
>      >>      To make changes to your subscription:
>      >> http://www.postgresql.org/mailpref/pgsql-jdbc
>      >>
>      >>
>      >>
>      >>
>      >>
>      >>
>      >> --
>      >> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org
>     <mailto:pgsql-jdbc@postgresql.org>)
>      >> To make changes to your subscription:
>      >> http://www.postgresql.org/mailpref/pgsql-jdbc
>      >
>
>
>
>     --
>     Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org
>     <mailto:pgsql-jdbc@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/mailpref/pgsql-jdbc

> I would like to start it. I do realize that my lack of time is probably
> paramount. But it needs to be solved.

I'll speak from my own experiences (XA Interleaving) and from watching
the mailing list over the last few months. Keep in mind, these are my
impressions, which are meant in no way to condemn, vilify, or point the
finger at any individual. Rather, I think it points to some cultural
pressures on the project as a whole.

* There are currently six open pull requests [1], some of which date
back 10 months. I can understand not merging a pull request. But things
this old that aren't merged probably ought to be closed.

* Initially when we contacted the list about implementing interleaving
we got everything from (paraphrased) 'it's a good idea' to 'if you need
it then you are doing it wrong'. Everything from our need for it to how
we eventually implemented was ridiculed.

* I finally took the time to jump through all the political hoops to
clean up the pull request (I still don't understand how a visual diff on
github is too hard to follow?!) I created a few months ago into two new
pull requests. It's been 3 days, and there's be zero activity or
comments on the requests. That seems odd. This is not a minor feature.

* I got the distinct impression that this project consists of an 'old
boys club' of developers who've worked on this project for a long time.
Outsiders seem to be treated in an almost hostile manner.

* A long-standing contributors misplaced emotional attachment to their
code should not justify holding on to artifacts which go against logic,
reason, and current best practices.

* It seems as though the project is resistant to any form of code-change
beyond a trivial bug fix to existing code. This seems like a release
management failure more than anything.

I completely agree with the assertion that it's easier to fork this
project than it is to contribute back to it. I will openly admit that
I've considered forking this project personally.

I've only been around since late January / early February, so I hope my
perspective in some way helps.

Regards,
-Bryan Varner


[1]: https://github.com/pgjdbc/pgjdbc/pulls

> Fair enough although 2 of them are yours...

Indeed. Like I said, this isn't meant in a 'condemning' manner.

> Well you posted it on a weekend, so I'd say 1 day really.

Fair enough.

>     * I got the distinct impression that this project consists of an
>     'old boys club' of developers who've worked on this project for a
>     long time. Outsiders seem to be treated in an almost hostile manner.
>
>
> Are you referring to the JDBC project or the postgresql project as a
> whole ?

This, the jdbc project.

> I would have to agree large changes are difficult to consume as we don't
> have the resources to review them, and the project is mainly in
> maintenance mode.

Well, if the project is in maintenance mode, how does it handle new JDBC
releases and is there a strategic goal for updating or EOLing specific
features / legacy JDBC versions or JDKs?

If there's no path 'forward' (or at least letting go of the past) then
we'll always have the same driver. Not that stability is a bad thing,
but I think there maybe some type of balance between maintaining what's
there and incrementally improving or retiring parts of the code base of
limited value.

> 3) Resistance
> When I introduced my project the longest discussion we had was about how
> it was packaged. I am using maven and hadn’t gotten around to having it
> make a single jar with dependencies. When I cleared up that indeed it
> would be a single jar, it then moved on to the idea that any third party
> library should be disallowed. In my view there were some that were
> looking for any reason that could be found to write off my work and
> leave the driver as is. The reason I wrote to the list, which I clearly
> stated then, was to introduce my project was to discuss how to include
> my work in the larger project and mainstream it in the long run; that
> discussion never happened. No decision makers ever bothered to take a
> look at my code and report back. All we did was discuss minutia. I came
> away with the distinct impression that I should just keep working on my
> project in isolation.

Kevin,

I'd like to apologize if my response [1] added to your impression.
Packaging the thing up with maven-shade-plugin would suffice for me. The
organizations I know of which would object to importing netty code
aren't a natural fit for F/OSS (and postgresql) anyhow.

In re-implementing the XA data source, it astounded me how many
completely non-technical arguments were 'blocking' it's incorporation.

Regards,
-Bryan Varner

[1] http://www.postgresql.org/message-id/513F797A.2060408@polarislabs.com

Dave Cramer-8 wrote
>> 2) Maintenance Mode
>> You can tell the code is in maintenance mode just by reading it.  I won’t
>> repeat my previous discussions about the state of the code now but there
>> is
>> quite obvious code rot going on as features are slapped together in the
>> most fragile of ways. I believe that is what any project in “maintenance
>> mode” gets; just another name for a project experiencing code rot.  It
>> seemed obvious to me, both then and now, that working within the current
>> framework was going to take a lot longer than just rolling a new one;
>> that
>> comes from somebody who now has a near complete implementation of
>> java.sql.Driver.
>>

I cannot seem to get a coherent thought going here but just some thoughts
for everyone to consider.

I think one of the biggest changes that could be made, given that the
current driver has accumulated so much technical (and process) debt - not to
mention the stability that it needs - would be for the PostgreSQL Global
Development Group to become not only the maintainer of the current driver
but also a trusted resource that PostgreSQL+Java users can rely upon to help
them evaluate the various implementations of the JDBC driver that exist to
meet the diverse needs of the community.  It should enforce minimal
standards by creating a black/white lists with specific details as to
missing mandatory features or structure (i.e., licensing; timely response to
community feedback like pull requests; etc...).

The goal should be to identify one or more reference implementations for the
current pair of JVM+PostgreSQL and assist whomever "maintains" that
implementation.  This implementation should try to strive for backward
compatibility but implementing all the specification/database features is of
a higher priority.

As a user I would want an idea of the trade-offs between different
implementations to aid in researching and some guidance on how to properly
evaluate different drivers in my custom environment.

Without a strong JDBC community the attractiveness of PostgreSQL as a
back-end is going to stagnate.  Technological innovation is needed but the
way it is occurring right now has the downside of giving off a "fracturing"
vibe.  The programmers are not going to be able (or want) to solve that part
of the puzzle.  Ideally one of the vendors who wants to innovate on the
driver could take some of these observations and leverage it into something
they can earn money on (likely via consulting on things like performance -
and other kinds of - testing).

I am likely a typical user which means that the status-quo really hasn't
been something that I've said to myself that there is a problem.  Mailing
list traffic is pretty light and because it is in maintenance mode there
just isn't much excitement in being noisy just to tell people you are still
alive.  Putting things into core indeed has a high barrier but that is
because the vast majority of people simply look at the current driver as
being canon and want their existing software to continue working the way it
did on the last version.  Thus some form of forking is going to be required
- the question is who creates and maintains the forks and how long should
they survive.

Sorry for the rambling especially since I'm not currently planning to
actually act on my own advice but hopefully people will find some value in
my perspective.

David J.






--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5760763.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

Hi Dave, et al.

I've been using the JDBC driver for many years and have followed this
list for a great number as well. Firstly I'd like to thank Dave and the
other lead developers for their work for which without their wouldn't be
a java driver.

I too have a few comments that I hope you don't mind me sharing:

I would have to agree that sometimes it does feel like the project is
like a clique than an open source project, I've witnessed and partially
been involved with suggestions for which it feels are either ignored or
quashed from on high. I fully understand the need to maintain stability
and that the driver is used by many large corporations/projects, but I
don't feel this should be a limit to change or expansion.
One example of this was that of switching the project to use features of
a newer JDK version - 1.4 to 1.5 from memory, which given JDK6 has just
been discontinued seems hard to believe. I think these kind of
discussions are going to be (and have been) more common as people
require features of the newer specs (both JDK and JDBC). Given the
project is relatively stable with very few bug fixes (and usually minor
at that), it would seem possible to freeze the "old" versions and only
backport serious bugs (if at all) - but I digess and this is left as
another topic of discussion.

Is there a formal process for submitting patches, I've believe it is
that diffs should be submitted to the list? Unfortunately personal
experience tells me that this doesn't seem to work as planned...

I feel it is a combination of these 2 that causes people (myself
included) to fork the project for personal projects. It would be nice if
these "personal" features could be re-integrated back into the main so
that everyone can benefit.

John

I mentioned it in my previous post, but what are the lists thoughts on
using a different versioning strategy for the driver in a similar manner
to other OS projects.

My suggestion would be to:
- freeze the current release at v1.x for partial JDBC4 support
- archive the pre JDBC4 versions completely
- start a new version 2, for example incorporating the major NIO and XA
changes previously discussed running on the current JDK incorporating
stubs or complete functions for the latest JDBC spec features as needed,
etc and supporting the latest versions of Postgres as appropriate

Work would progress with v2 with only significant bug fixes to then be
propagated back to v1.

Hopefully this reaches some compromise for the stability issues with
existing users who can remain on v1 with newer projects migrating to the v2.

At some point in the future I'd envisage a new version being released
for example with the release of JDK8 or JDBC5 as required..

John

On 6/24/2013 4:18 PM, Kevin Wooten wrote:
> Second, porting my implementation back to Java 5/6 and/or PostgreSQL
> servers prior to 9.2.  The current driver has lots of special case
> code for servers and now JDK’s that have been EOL’d.  My project
> implementation currently has none, it runs on JDK 7/JDBC 4.1 and
> Postgres >= 9.2.  I believe there is a more elegant way to handle
> these cases going forward than the option used in the mainstream
> project of abstract/concrete classes for each JDBC version. I think
> JDBC differences should be handled with the maven pre-processor plugin
> to conditionally compile for each JDBC. Server differences can still
> use special case code and/or polymorphic classes to address the
> problem/feature at hand.

speaking as a user and system administrator, I would NOT want to need to
use different JAR files for each {jvm,postgres} version. that would be a
nightmare.

we have a LOT of systems in our manufacturing operations that are
running older versions of {os, postgres, jvm} for various reasons, not
the least of which is upgrades often break things in very non-obvious ways.

--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

John R Pierce wrote
> On 6/24/2013 4:18 PM, Kevin Wooten wrote:
>> Second, porting my implementation back to Java 5/6 and/or PostgreSQL
>> servers prior to 9.2.  The current driver has lots of special case
>> code for servers and now JDK’s that have been EOL’d.  My project
>> implementation currently has none, it runs on JDK 7/JDBC 4.1 and
>> Postgres >= 9.2.  I believe there is a more elegant way to handle
>> these cases going forward than the option used in the mainstream
>> project of abstract/concrete classes for each JDBC version. I think
>> JDBC differences should be handled with the maven pre-processor plugin
>> to conditionally compile for each JDBC. Server differences can still
>> use special case code and/or polymorphic classes to address the
>> problem/feature at hand.
>
> speaking as a user and system administrator, I would NOT want to need to
> use different JAR files for each {jvm,postgres} version. that would be a
> nightmare.
>
> we have a LOT of systems in our manufacturing operations that are
> running older versions of {os, postgres, jvm} for various reasons, not
> the least of which is upgrades often break things in very non-obvious
> ways.

I really don't see how this a problem in the normal case where you'd pick a
JAR and then simply ignore upgrading as time progresses - just like you are
doing with everything else.

I would imagine that in most cases forward compatibility is maintained is
this scenario.  If you want to restrict yourself to
lowest-common-denominator you are free to do so.

Introducing new feature runs the risk of introducing bugs but at the same
time those features generally have value otherwise they would not have been
developed.  There needs to be some plan to get Java users access to the new
functionality when they use PostgreSQL.

At this point I can imagine that we'd break at Java 7 then the modern driver
would try to maintain backward compatibility as long as possible.  It would
be deprecated at some point and a post-modern driver based on Java 12 could
become the mainline driver.

I do not think our present situation is inherently a bad one or unexpected
given the unique requirements that manifest themselves by working in two
worlds.  Which is why being open to forks and/or custom implementations in
order to test-drive new features and other changes is worthwhile.  Leave the
"mainline" JAR focused on stability and compatibility over feature
implementation but give people the option to choose some other trade-off.
At some point the technical debt from stability/compatibility will result in
the new mainline driver arriving in the same "maintenance mode" status that
the current mainline driver exhibits.

David J.




--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5760798.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

On 6/24/2013 6:16 PM, David Johnston wrote:
>> speaking as a user and system administrator, I would NOT want to need to
>> >use different JAR files for each {jvm,postgres} version. that would be a
>> >nightmare.
>> >
>> >we have a LOT of systems in our manufacturing operations that are
>> >running older versions of {os, postgres, jvm} for various reasons, not
>> >the least of which is upgrades often break things in very non-obvious
>> >ways.
> I really don't see how this a problem in the normal case where you'd pick a
> JAR and then simply ignore upgrading as time progresses - just like you are
> doing with everything else.

currently, we bundle the postgresql.jar with our applications, and we
don't know what combination of systems it might end up being run on ...
the same package might land on solaris or AIX or Linux or even MS
Windows, and it might be run with anything from Java 1.5 or newer.   The
postgresql server might be 8.3, 8.4, 9.x.   as most of our deployments
end up deep in our Asian factories, the development group has little
control over the final runtime environment, and quite often new releases
of our packages are installed as application upgrades on existing
infrastructure hardware.

--
john r pierce                                      37N 122W
somewhere on the middle of the left coast

Well, there are already multiple jars for different jdbc version, so you should not simply use "one jar" strategy. It may work for you, but it may also produce problems on invalid jdbc version.
At the other hand, one can't expect that both latest server and jdk will be used on every installation. You should not force user to use jdk7 for postgresql 9.3 or visa versa.
At my opinion, new jdbc 4.1 driver can drop some legacy server versions support, but only some, not all of it.

Best regards, Vitalii Tymchyshyn.

On 24.06.2013 20:59, Bryan Varner wrote:
> * Initially when we contacted the list about implementing interleaving
> we got everything from (paraphrased) 'it's a good idea' to 'if you need
> it then you are doing it wrong'. Everything from our need for it to how
> we eventually implemented was ridiculed.

The way I recall those discussions is that I was against the idea of
juggling physical connections in the driver, while a few other people
were generally excited to see you working on it without commenting on
the details.

I spent a considerable amount of my time trying to understand the
problem you were seeing, looking at the patch itself, and crafting
replies to you. I'm really sorry if you felt that I ridiculed you - it
was definitely not meant like that.

> * I got the distinct impression that this project consists of an 'old
> boys club' of developers who've worked on this project for a long time.
> Outsiders seem to be treated in an almost hostile manner.
>
> * A long-standing contributors misplaced emotional attachment to their
> code should not justify holding on to artifacts which go against logic,
> reason, and current best practices.

Again I feel I might be responsible for these sentiments, as I don't
think anyone else objected strongly to your patch. I spent a lot of time
crafting my replies and I thought I explained my objections quite
thoroughly, but I'm sorry if it didn't get across that way. Let me
assure you that there is enough code of mine out there that I don't feel
particularly attached to any of it. My objections were purely technical.

> * It seems as though the project is resistant to any form of code-change
> beyond a trivial bug fix to existing code. This seems like a release
> management failure more than anything.

I don't think there's much resistance as such, just a lack of Dave's
time to review and commit patches. In fact, I get the feeling that
trivial bug fixes fall through the cracks just as easily as bigger code
changes - I've had a couple of my trivial patches linger for months, too.

The problem is that there isn't many people reviewing and committing
patches. Dave and Oliver are busy with other stuff.

We have some people who pop up every now and then with a patch, but how
do we get them involved in reviewing other people's work? How can we get
more people involved in doing the boring, janitorial work of making sure
that the driver works with supported all versions of JDBC and JRE?

- Heikki

<div>På tirsdag 25. juni 2013 kl. 15:44:49, skrev Dave Cramer <<a href="mailto:pg@fastcrypt.com"
target="_blank">pg@fastcrypt.com</a>>:</div><blockquotestyle="border-left: 1px solid rgb(204, 204, 204); margin: 0pt
0pt0pt 0.8ex; padding-left: 1ex;"><div dir="ltr">Here's the way I see this from my POV. <div> </div><div style="">First
someperspective. </div><div style=""> </div><div style="">There are approx. 5 people actively participating in this
discussion.1000's of other people are happy just downloading the driver. In my mind they are the market.</div><div
style=""> </div><divstyle="">Now some reality.</div><div style=""> </div><div style="">I have been maintaining the
driversince around 2000. Since that time others have contributed greatly. Namely Kris Jurka and Oliver Jowett stand out
aspeople who have stepped up in a big way and in fact taken over much of the work when I was unavailable</div><div
style=""> </div><divstyle="">At the moment I am the only one left. I have never been paid for any of this. I am not
expectingto, but this reality means that I have limited time to work on it.</div><div style=""> </div><div
style="">Otherthan Kris and Oliver, there have been others who have expressed interest in donating their time and
effort,for whatever reason they do not remain active. </div><div style=""> </div><div style="">In the case of Kevin's
10month old patch Craig Ringer originally reviewed that patch and I left him in charge of it. As a result it became
staleand Kevin decided his time was better spent writing a whole new driver. </div><div style=""> </div><div
style="">Inmost open source projects people get involved slowly. Patches which involve large changes to the codebase
arenot accepted by people who are not going to take future responsibility for them. </div><div style=""> </div><div
style="">Keepin mind that I have considerable knowledge of how the code works right now. If I were to accept a huge
change,then I become responsible for it. Unless I see some continued commitment from someone how do I know they will
continueto be responsible for this new code ?</div><div style=""> </div><div style=""> </div><div style="">Moving
forward.As I see it the number one problem is lack of resources. Instead of opting for wholesale change the project
needsresources. Someone else to review patches, someone to work on the website. Someone to deploy to maven.</div><div
style=""> </div><divstyle="">Anyone feel like volunteering ?</div></div></blockquote><div> </div><div>As a developer,
amongthose other 1000s of people, having used PG from JVM-based languages for the past 13 years I'm really starting to
missbetter support for UDT and BLOBs. As development seems to have stagnated in the standard-driver I very much welcome
Kevin'snew driver (impressive work man!) and hope it will be the start of "pgjdbc-NG"
driver.</div><div> </div><div>Thereare a lot of people who don't care for JAVA < 7</div><div> </div><div
class="origo-email-signature">--<br/> Andreas Joseph Krogh <andreak@officenet.no>      mob: +47 909 56 963<br />
SeniorSoftware Developer / CTO - OfficeNet AS - http://www.officenet.no<br /> Public key:
http://home.officenet.no/~andreak/public_key.asc</div><div> </div>

Heikki Linnakangas wrote:
> On 24.06.2013 20:59, Bryan Varner wrote:
>> * Initially when we contacted the list about implementing interleaving
>> we got everything from (paraphrased) 'it's a good idea' to 'if you need
> ......
 > ......
 > ......
 > ......
> assure you that there is enough code of mine out there that I don't feel
> particularly attached to any of it. My objections were purely technical.
>
>> * It seems as though the project is resistant to any form of code-change
>> beyond a trivial bug fix to existing code. This seems like a release
>> management failure more than anything.
>
> I don't think there's much resistance as such, just a lack of Dave's
> time to review and commit patches. In fact, I get the feeling that
> trivial bug fixes fall through the cracks just as easily as bigger code
> changes - I've had a couple of my trivial patches linger for months, too.
>
> The problem is that there isn't many people reviewing and committing
> patches. Dave and Oliver are busy with other stuff.
>
> We have some people who pop up every now and then with a patch, but how
> do we get them involved in reviewing other people's work? How can we get
> more people involved in doing the boring, janitorial work of making sure
> that the driver works with supported all versions of JDBC and JRE?
>
> - Heikki

I think projects really get pushed forward either by a passionate leader
or money. Since pgJDBC is free then the latter is not the motivating factor.
Not only does a leader need to be passonate but also have a high degree
of organizational skills. Those skill can be used effectively to make decisions
on work prioritization and communicating to others areas where they could
contribute. All of this should take place in a open simple to understand
manner even for the newbies. The last real issue is time or a least a person
that has high degree ability of managing their time.

I thought a while back that when Dave asked for a discussion with updating
the web site that some effort might take place in perhaps providing a means
to make information, (patches, todos, issues), more visible to newbies and
regulars alike. That seems to have died like other efforts in the works on
the list. Perhaps some new leadership is in order with oversite by Dave,
Kris, Oliver, ... others?

Maybe that leadership should be one of those that is exercising passion by
creating one of the forks. A warning though is in order, a good leader is
not necessarily a good coder and does all the work. That person needs to
have the qualities listed above and the ability to enlist, motivate others.

The PostgreSQL server in the last few years seems to be pushed forward by
some regulars that appears to me to be backed by companies that have an
interest in getting work done. Perhaps the pgJDBC may also need this type of
help from those that need the JDBC.

danap.

Hi Dave,

>
> Moving forward. As I see it the number one problem is lack of resources.
> Instead of opting for wholesale change the project needs resources.
> Someone else to review patches, someone to work on the website. Someone
> to deploy to maven.
>
> Anyone feel like volunteering ?
>

Let me say a thank you to all the work you have done for the JDBC
driver. I'm happy to volunteer for both patch review and handling Maven.
As I already run the JDBC buildfarm
(www.pgbuildfarm.org/cgi-bin/show_status.pl?member=piapiac) I have a
stable, repeatable build environment that can be used to make a driver
release and push it to Maven. I've not done a push to central before but
I have run a number of CI environments with nexus. I recall there being
a number of discussions early this year so I'll make a start there.

Kind regards,
--
Mike Fowler
Registered Linux user: 379787

i can help as well.

I have indicated I would be willing to help with the web page, but last that
issue came up the use of Apache Forest was considered the default. After
reviewing it I thought it was not conducive to a simple approach to conveying
information. I really mean basic information and providing a mechanism to convey
development work. The keys areas for development it seems to me are todos and
patches? Without these being clearly accurate and accessable to individuals
then no clear goals are communicated.

I would be willing to research as indicated before and alternative to Apache
Forest, but will find a way to use if that remains the default.

---------------------------------------
So may I summarize:

** LACK of RESOURCES:

1. Review Patches (Open)
2. Maven Deployment, Mike Fowler, Build to be still controlled by Dave?
3. Website, Dana Proctor

Kevin Carr in what way would you be willing to contribute, area(s)?

---------------------------------------
** Now I suppose this will generally address the maintenance of the existing
code, But it does not address the issue of pushing the Driver into compliance
with Java 7, 8, etc. and the forks.

This is where I would like to see the website setup for polling, it seems
that the conscious seems to be that there should be:

1. Current pgJDBC to be maintained, but not be pushed forward?
2. Fork(s) to be Version 2 for Java 7, 8 support?

danap.

Mike Fowler wrote:
> Hi Dave,
>
>>
>> Moving forward. As I see it the number one problem is lack of resources.
>> Instead of opting for wholesale change the project needs resources.
>> Someone else to review patches, someone to work on the website. Someone
>> to deploy to maven.
>>
>> Anyone feel like volunteering ?
>>
>
> Let me say a thank you to all the work you have done for the JDBC
> driver. I'm happy to volunteer for both patch review and handling Maven.
> As I already run the JDBC buildfarm
> (www.pgbuildfarm.org/cgi-bin/show_status.pl?member=piapiac) I have a
> stable, repeatable build environment that can be used to make a driver
> release and push it to Maven. I've not done a push to central before but
> I have run a number of CI environments with nexus. I recall there being
> a number of discussions early this year so I'll make a start there.
>
> Kind regards,

On Jun 26, 2013, at 11:58 AM, Dave Cramer <pg@fastcrypt.com> wrote:

> Currently I am the only committer, (Kris is still but he's not active now) I would remain that way for a while til I
seewhere this is going. 
>
> Dana , have a look at http://jekyllrb.com/
>
> As for other people who have offered help Stephen Nelson has shown some interest.
>

First, thanks so much for your (and Kris's, and all the other committers') hard work.  It is appreciated!  The Postgres
JDBCdriver has been stable and reliable and a core part of a lot of the projects I currently work on. 

It sounds like at this point, even if the decision is to stay with the current mainline for the time being, the project
needssome "new blood" to ensure it keeps going in the case where you lose the interest or time to donate to the
project.

I would happily donate some time to doing code review and implementing improvements.

Maybe you (or everyone as a group?) should draw up some guidelines on what sort of expectations there are of
committers. I could see introducing ten new committers to help with code review all at the same time causing a lot of
instabilityboth in the driver and the project, unless everyone agrees on what are / aren't the goals of the current
JDBCdriver.  I think "not destabilizing the current driver" is a worthy priority, given how many people depend on it… 

On 06/26/2013 03:25 PM, Kevin Wooten wrote:
> Obviously I'm willing and able to donate a large amount of time to a
> JDBC driver for PostgreSQL...
>
> My only issue at this point is that I have a large investment of time in
> the alternative driver I created. It's near complete and supports all of
> the advanced features the mainstream driver is lacking. It has a lot
> going for it in terms of clean architecture as well (my completely
> biased opinion of course). I am not really interested in abandoning my
> efforts only to try and enhance the current driver. So if there is no
> clear way to migrate much or all of it into the mainstream driver; I am
> not sure how much time I would have left.

I would be interested in contributing some of my personal time to
providing effort toward the various datasource implementations which I
think are still missing from your driver, Kevin. Feel free to contact me
off-list if that's something you're interested in.

Regards,
-Bryan Varner

Thanks Scott.

Dave I will take a look at the web link you indicated. I propose first that the
website should become the focus first to detail the information on development
work. I can work with you on that over the next week or so. I would really like
to keep it simple. Perhaps Scott can also give input or help once a decision is
made on what to do in that focus.

In the mean time I started the implementation of a poll to address the 2nd
issue of driver forking to get an idea of the communities real status to this
question. I can probably get that poll on my website tomorrow or the next. I
can post back then for people to vote.

The poll can also give and idea of the real participation of the mailing list.
Perhaps it needs cleaned out. Maybe only a few dozen people are really active
and interested in the pjJDBC. Maybe most just think go with the fork. In either
of those cases reorganizing the core project is maybe not worth the effort
other than getting the backlog of patches, etc. performed.

danap.

Kevin Carr wrote:
> I am a heavy java programmer.  (Going on about 12+ years now.)  I know
> web development, and use maven heavily.
>
> So I can help with all areas as needed.
>
> I go by Scott.

In my view the driver has already been forked by Kevin Wooten so it's more of a case of will it be an official fork or not? I think it would be a good idea to harness the enthusiasm from the contributors to the newer driver. However I think it would be a shame and a mistake to throw away the work that has gone into the stable driver. If it's not feasible to merge the code of both drivers I do think it would be useful to share what can be - particularly the functional tests.

If it is decided to promote both drivers as official projects I think, for the benefit of the users confused about the choice, that the newer driver be labelled as a beta until such time as everyone is convinced in its stability and functionality, that it is pushed as the current driver and then the older one can become legacy.

My interest in the project has mainly been around getting the jars automatically uploaded to Maven. I'm interested in reviewing driver patches but I don't have the knowledge of the protocol at the moment to provide any useful feedback other than obvious things. I would like to experiment with an alternative build system called Gradle and get continuous integration and deployment sorted out so that upon check-in the driver is built on a variety of platforms, tested on a variety of servers and automatically deployed to Maven central as well as the website. My time is a bit variable with kids/work/life taking a big chunk of it so I would like to collaborate with people on the project. 

Cheers,

Stephen

1. recommending the existing driver for JDBC3 and earlier
2. and Kevin's driver for JDBC4 and greater?

On Jun 26, 2013, at 3:29 PM, "Marc G. Fournier" <scrappy@hub.org> wrote:

>> How about, when Kevin's driver is ready:
>>     • recommending the existing driver for JDBC3 and earlier
>>     • and Kevin's driver for JDBC4 and greater?
>
> Why not just create a 'pre-JDBC4 branch for the current official one and import Kevin's as JDBC4, for going forward?
WhatI've read seems to indicate a reluctance to make a whole whack of changes on the current code, so putting it over
toa branch shouldn't cause to much angst, should it? 

Because currently the fork has zero adoption and no momentum, whereas the existing driver has a huge install base of
peoplewho expect to continue to receive updates going forward. 

Not that it couldn't ever be the main branch, but I think you guys are jumping the gun by a lot.  And I'm even a fan of
doingthe cool new shiny stuff. 

The existing driver is tried and true, and I think for a project of PG-JDBC's stature it's going to take a lot more
thanan alpha driver codebase to switch the project over like that. 

On Jun 26, 2013, at 3:44 PM, Dave Cramer <pg@fastcrypt.com> wrote:

Well I'm curious about a few things.

1) I just tried to build it, given I have no idea how it's not surprising it failed to build. But there are no clear instructions on how to build it.

It's a maven build 'mvn package' should suffice.  About 4 or 5 other people have contributed in some way and nobody has yet run into issues building the project.  You are correct there isn't much documentation for anything as I am the only regular contributor it hasn't been necessary.  On the github page there is a link to a snapshot release build for people to download and try (a single jar).

2) it appears to pull in at least a few other jars, how big is it when it's built? I personally use this on an embedded system where size matters

It only uses Netty for async i/o and Guava for utils (which can be removed).  Currently the jar is built using the maven assembly plugin and produces a large jar because it pulls all of Netty and Guava into it; which is 3.8MB.   Netty and Guava combine to contribute over 3MB of that size but the necessary bits of both projects are small.  Switching from the maven assembly plugin to the maven shade plugin would reduce the size dramatically as it only pulls in the used class files.  My best guess would be that it ends up around 700k or so.  Given that the current driver is around 580k it shouldn't be that much different in the final version.

3) It's my understanding that there will be resistance by larger consumers to using external jars even if they are built into a single jar.

I don't care to get into this discussion again.  I'll just say this… Netty is one of the few well respected async i/o libraries out there.  Synchronous i/o is very hard to get right without a framework and asynchronous i/o is downright impossible. The current driver doesn't use async i/o and has to program around deadlocks/stalls related to it's synchronous i/o approach; and according to the current code comments doesn't seem to be completely protected against them.  For these reasons, and the added benefits of supporting asynchronous notifications from the server make using a library a no-brainer.

4) as it appears to only target one JDBC version what is the plan to deal with other versions without using abstract classes like the current jar, and if so how is that any better ?

To support other JDBC versions I plan to use a maven java preprocessor plugin rather than the abstract/concrete class approach which make the code very to get introduced to.

5) does it support all current versions of postgresql (ie back to 8.4) ?

No. It was written knowing it's adoption would take time and as such I wrote it specifically for 9.2+.

Lastly, I've never heard of an open source project where a bunch of totally new people come in and propose forking the project without any prior commitment to the project ?

Why is there a big desire to drop the existing code base just to support a few new very unused features (I'm presuming this because there aren't that many requests for them) ?

I believe this speaks to the larger point that is at discussion here.  A number of people are/were enthusiastic to help out with the mainstream driver by adding support for new features in PostgreSQL itself and bringing the driver up to date with regards to JDBC and other spec. conformance.  Due to the issues  and perceptions, that I and others, laid out at the opening of this thread it seems a number of people think this project is moving at too slow a pace.  It also seems that a number of people think that the project could move forward faster by not specifically tying new development to the mainstream codebase.

Alas, as we discuss this, it's becoming obvious that point I've been trying to make is somewhat failing on deaf ears.  The current driver is a hinderance to people who want to use the new and interesting features of PostgreSQL.   In my example, UDT's are well supported, and have been for years, in both PostgreSQL and JDBC but the driver has completely ignored them for years as well.   As a person who has implemented these new features I can tell you a major overhaul in core is required to add these features properly.  All I've heard in response is "don't touch it, it's stable!".  So, I supposed you'll continue by band aiding it yet again; adding just enough code to claim some level of conformance and leave it in a state extremely far behind the server itself.

I want to add one last example to further my point.  You asked "Why is there a big desire to drop the existing code base just to support a few new very unused features?".  It's not just to support some unused features.  Java 6/JDBC 4 has been EOL'd by Oracle and this driver hasn't even bothered to support the Java 7/JDBC 4.1 spec.  That's the whole reason this thread got started. Somebody was looking for a feature the Java documentation clearly said should be there and could not find it.  Confusion ensued and now here we are.  That, to me, speaks volumes about the lethargic pace of this project.

My apologies for joining the discussion and especially for my above rant.  I never intended to disrupt this project as it appears you believe it has.  Actually, I intended to come here and help out in an impactful way.  I wanted a driver that unlocks all the potential of the server that I prefer and instead of complaining, I chose to do something about it.   At this point it sounds like my best bet is to quietly return to my work on that project and stop causing a disruption around here.  I will say that I welcome any and all people who would like to join me in my effort.  It seems the political climate is just not there for joining forces.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Wed, Jun 26, 2013 at 6:29 PM, Marc G. Fournier <scrappy@hub.org> wrote:

On 2013-06-26, at 15:15 , Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:

On 27/06/13 09:45, Stephen Nelson wrote:

In my view the driver has already been forked by Kevin Wooten so it's more of a case of will it be an official fork or not? I think it would be a good idea to harness the enthusiasm from the contributors to the newer driver. However I think it would be a shame and a mistake to throw away the work that has gone into the stable driver. If it's not feasible to merge the code of both drivers I do think it would be useful to share what can be - particularly the functional tests.

If it is decided to promote both drivers as official projects I think, for the benefit of the users confused about the choice, that the newer driver be labelled as a beta until such time as everyone is convinced in its stability and functionality, that it is pushed as the current driver and then the older one can become legacy.

My interest in the project has mainly been around getting the jars automatically uploaded to Maven. I'm interested in reviewing driver patches but I don't have the knowledge of the protocol at the moment to provide any useful feedback other than obvious things. I would like to experiment with an alternative build system called Gradle and get continuous integration and deployment sorted out so that upon check-in the driver is built on a variety of platforms, tested on a variety of servers and automatically deployed to Maven central as well as the website. My time is a bit variable with kids/work/life taking a big chunk of it so I would like to collaborate with people on the project. 

Cheers,

Stephen

How about, when Kevin's driver is ready:

1. recommending the existing driver for JDBC3 and earlier
2. and Kevin's driver for JDBC4 and greater?

Why not just create a 'pre-JDBC4 branch for the current official one and import Kevin's as JDBC4, for going forward?  What I've read seems to indicate a reluctance to make a whole whack of changes on the current code, so putting it over to a branch shouldn't cause to much angst, should it?

<div>På torsdag 27. juni 2013 kl. 02:20:17, skrev Gavin Flower <<a href="mailto:GavinFlower@archidevsys.co.nz"
target="_blank">GavinFlower@archidevsys.co.nz</a>>:</div><blockquotestyle="border-left: 1px solid rgb(204, 204,
204);margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="moz-cite-prefix">On 27/06/13 11:57, Kevin Wooten
wrote:</div><blockquotecite="mid:9C4E6298-527E-4142-ACD0-0015FFBA7B5F@me.com" type="cite"><div><div>On Jun 26, 2013, at
3:44PM, Dave Cramer <<a href="mailto:pg@fastcrypt.com" moz-do-not-send="true"
target="_blank">pg@fastcrypt.com</a>>wrote:</div>   <blockquote type="cite"><div dir="ltr">Well I'm curious about a
fewthings. <div> </div><div style="">1) I just tried to build it, given I have no idea how it's not surprising it
failedto build. But there are no clear instructions on how to build it.</div></div></blockquote><div> </div> It's a
mavenbuild 'mvn package' should suffice.  About 4 or 5 other people have contributed in some way and nobody has yet run
intoissues building the project.  You are correct there isn't much documentation for anything as I am the only regular
contributorit hasn't been necessary.  On the github page there is a link to a snapshot release build for people to
downloadand try (a single jar).<br />   <blockquote type="cite"><div dir="ltr"><div style="">2) it appears to pull in
atleast a few other jars, how big is it when it's built? I personally use this on an embedded system where size
matters</div></div></blockquote><div> </div><div>Itonly uses Netty for async i/o and Guava for utils (which can be
removed). Currently the jar is built using the maven assembly plugin and produces a large jar because it pulls all of
Nettyand Guava into it; which is 3.8MB.   Netty and Guava combine to contribute over 3MB of that size but the necessary
bitsof both projects are small.  Switching from the maven assembly plugin to the maven shade plugin would reduce the
sizedramatically as it only pulls in the used class files.  My best guess would be that it ends up around 700k or so.
 Giventhat the current driver is around 580k it shouldn't be that much different in the final version.</div>  
<blockquotetype="cite"><div dir="ltr"><div style="">3) It's my understanding that there will be resistance by larger
consumersto using external jars even if they are built into a single jar.</div></div></blockquote><div> </div><div>I
don'tcare to get into this discussion again.  I'll just say this… Netty is one of the few well respected async i/o
librariesout there.  Synchronous i/o is very hard to get right without a framework and asynchronous i/o is downright
impossible.The current driver doesn't use async i/o and has to program around deadlocks/stalls related to it's
synchronousi/o approach; and according to the current code comments doesn't seem to be completely protected against
them. For these reasons, and the added benefits of supporting asynchronous notifications from the server make using a
librarya no-brainer.</div>   <blockquote type="cite"><div dir="ltr"><div style=""> </div><div style="">4) as it appears
toonly target one JDBC version what is the plan to deal with other versions without using abstract classes like the
currentjar, and if so how is that any better ?</div></div></blockquote><div> </div><div>To support other JDBC versions
Iplan to use a maven java preprocessor plugin rather than the abstract/concrete class approach which make the code very
toget introduced to.</div>   <blockquote type="cite"><div dir="ltr"><div style="">5) does it support all current
versionsof postgresql (ie back to 8.4) ?</div></div></blockquote><div> </div> No. It was written knowing it's adoption
wouldtake time and as such I wrote it specifically for 9.2+.</div><div> </div><div><blockquote type="cite"><div
dir="ltr"><divstyle=""> </div><div style="">Lastly, I've never heard of an open source project where a bunch of totally
newpeople come in and propose forking the project without any prior commitment to the project
?</div></div></blockquote><blockquotetype="cite"><div dir="ltr"><div style=""> </div><div style="">Why is there a big
desireto drop the existing code base just to support a few new very unused features (I'm presuming this because there
aren'tthat many requests for them) ?</div><div style=""> </div></div></blockquote><div> </div><div><div>I believe this
speaksto the larger point that is at discussion here.  A number of people are/were enthusiastic to help out with the
mainstreamdriver by adding support for new features in PostgreSQL itself and bringing the driver up to date with
regardsto JDBC and other spec. conformance.  Due to the issues  and perceptions, that I and others, laid out at the
openingof this thread it seems a number of people think this project is moving at too slow a pace.  It also seems that
anumber of people think that the project could move forward faster by not specifically tying new development to the
mainstreamcodebase.</div><div> </div><div>Alas, as we discuss this, it's becoming obvious that point I've been trying
tomake is somewhat failing on deaf ears.  The current driver is a hinderance to people who want to use the new and
interestingfeatures of PostgreSQL.   In my example, UDT's are well supported, and have been for years, in both
PostgreSQLand JDBC but the driver has completely ignored them for years as well.   As a person who has implemented
thesenew features I can tell you a major overhaul in core is required to add these features properly.  All I've heard
inresponse is "don't touch it, it's stable!".  So, I supposed you'll continue by band aiding it yet again; adding just
enoughcode to claim some level of conformance and leave it in a state extremely far behind the server
itself.</div><div> </div><div>Iwant to add one last example to further my point.  You asked "Why is there a big desire
todrop the existing code base just to support a few new very unused features?".  It's not just to support some unused
features. Java 6/JDBC 4 has been EOL'd by Oracle and this driver hasn't even bothered to support the Java 7/JDBC 4.1
spec. That's the whole reason this thread got started. Somebody was looking for a feature the Java documentation
clearlysaid should be there and could not find it.  Confusion ensued and now here we are.  That, to me, speaks volumes
aboutthe lethargic pace of this project.</div><div> </div><div>My apologies for joining the discussion and especially
formy above rant.  I never intended to disrupt this project as it appears you believe it has.  Actually, I intended to
comehere and help out in an impactful way.  I wanted a driver that unlocks all the potential of the server that I
preferand instead of complaining, I chose to do something about it.   At this point it sounds like my best bet is to
quietlyreturn to my work on that project and stop causing a disruption around here.  I will say that I welcome any and
allpeople who would like to join me in my effort.  It seems the political climate is just not there for joining
forces.</div><div> </div></div><blockquotetype="cite"><div dir="ltr"><div style=""> </div></div><div
class="gmail_extra"> <div>Dave Cramer<br /><br /> dave.cramer(at)credativ(dot)ca<br /><a href="http://www.credativ.ca/"
moz-do-not-send="true"target="_blank">http://www.credativ.ca</a></div>   <div class="gmail_quote">On Wed, Jun 26, 2013
at6:29 PM, Marc G. Fournier <span dir="ltr"><<a href="mailto:scrappy@hub.org" moz-do-not-send="true"
target="_blank">scrappy@hub.org</a>></span>wrote: <blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px#ccc solid;padding-left:1ex"><div style="word-wrap:break-word">  <div><div class="im"><div>On
2013-06-26,at 15:15 , Gavin Flower <<a href="mailto:GavinFlower@archidevsys.co.nz" moz-do-not-send="true"
target="_blank">GavinFlower@archidevsys.co.nz</a>>wrote:</div>   <blockquote type="cite"><div bgcolor="#FFFFFF"
text="#000000"><div>On27/06/13 09:45, Stephen Nelson wrote:</div><blockquote type="cite"><div dir="ltr"><div
class="gmail_extra">Inmy view the driver has already been forked by Kevin Wooten so it's more of a case of will it be
anofficial fork or not? I think it would be a good idea to harness the enthusiasm from the contributors to the newer
driver.However I think it would be a shame and a mistake to throw away the work that has gone into the stable driver.
Ifit's not feasible to merge the code of both drivers I do think it would be useful to share what can be - particularly
thefunctional tests.</div><div class="gmail_extra"> </div><div class="gmail_extra">If it is decided to promote both
driversas official projects I think, for the benefit of the users confused about the choice, that the newer driver be
labelledas a beta until such time as everyone is convinced in its stability and functionality, that it is pushed as the
currentdriver and then the older one can become legacy.</div><div class="gmail_extra"> </div><div
class="gmail_extra">Myinterest in the project has mainly been around getting the jars automatically uploaded to Maven.
I'minterested in reviewing driver patches but I don't have the knowledge of the protocol at the moment to provide any
usefulfeedback other than obvious things. I would like to experiment with an alternative build system called Gradle and
getcontinuous integration and deployment sorted out so that upon check-in the driver is built on a variety of
platforms,tested on a variety of servers and automatically deployed to Maven central as well as the website. My time is
abit variable with kids/work/life taking a big chunk of it so I would like to collaborate with people on the
project. </div><divclass="gmail_extra"> </div><div class="gmail_extra">Cheers,</div><div
class="gmail_extra"> </div><divclass="gmail_extra">Stephen</div></div></blockquote><font size="-1">How about</font>,
whenKevin's driver is ready: <ol><li>recommending the existing driver for JDBC3 and earlier<li>and Kevin's driver for
JDBC4and greater?</ol></div></blockquote><div> </div></div> Why not just create a 'pre-JDBC4 branch for the current
officialone and import Kevin's as JDBC4, for going forward?  What I've read seems to indicate a reluctance to make a
wholewhack of changes on the current code, so putting it over to a branch shouldn't cause to much angst, should
it?</div><div> </div><div> </div></div></blockquote></div></div></blockquote></div></blockquote><fontsize="-1"><font
size="-1"><fontsize="-1">Kevin, w</font>hile </font>I can give you only moral support</font> - I would really like you
tocontinue!</blockquote><div> </div><div>+1 for Kevin's driver and hopefully an actively developed
driver.</div><div> </div><div>Isee Kevin's driver also supports Connection.createBlob, which is handy for EclipseLink
users(which I'm planning on migrating to, from Hibernate) as EclipseLink doesn't offer a blog-helper util for creating
blobs,like Hibernate does.</div><div> </div><div>Kevin; I have quite a large project and I'm willing to give your
drivera spin. Will give feedback soon.</div><div> </div><div class="origo-email-signature">--<br /> Andreas Joseph
Krogh<andreak@officenet.no>      mob: +47 909 56 963<br /> Senior Software Developer / CTO - OfficeNet AS -
http://www.officenet.no<br/> Public key: http://home.officenet.no/~andreak/public_key.asc</div><div> </div> 

I fully agree with Steven's point re. the existing driver's level of
stability. I also agree that without the efforts from a few key people,
getting PostgreSQL adoption to where it is today in the Java space would
simply not have a happened. Personally I am very grateful to those people.

 From my perspective (a corporate Java developer and PostgreSQL user for
more years than I care to remember), here are my views:-

1. Stability has to be top priority. I say this on the basis that every
month that goes by, more and more organisations are either evaluating or
making a switch away from proprietary databases and onto PostgreSQL. A
great many of these are Java shops using some form of server environment
such as Tomcat, Glassfish, WebSphere etc., so access will normally be
via the JDBC Driver. To de-stabilise the existing driver in any way,
shape or form, has the potential to de-rail the adoption of PostgreSQL
in a big, big way. Do not do it!

2. To say that anything prior to Java7 is "dead" is ridiculous at this
point in time, at least in a commercial environment. In one or two
year's time however it may be different. Yes, there may be compelling
security reasons to upgrade from 6 to 7, but in an existing deployed
commercial environment happily running Java 5 or 6, you are only going
to upgrade to Java 7 if there is a very good reason to do so. I can
recall numerous examples of a "simple" Java version upgrade breaking one
or more production systems. I've just checked the very latest WebShere
offering from IBM (Version 8.5.5) and that still installs Java6 by default.

3. Yes, the current driver is not perfect, and there are several missing
features which most people have identified as being more than just a
nice to have. In particular the work on getting XA support working
correctly by Bryan Varner is something that will certainly help with
installations running high transaction rate Glassfish or WebSphere
installations and using the XA mode driver is a requirement. The big
question is how do we get these new features and major fixes into the
current driver without risk of destabilisation?

Here's my suggestion on the way forward:

1. Retain the existing driver in its current form (JDBC4), archive it
and maintain it for major fixes only. Ship this as "pg-jdbc4-stable.jar"
or similar.
2. Where feasible, start adding in features taken from the other
initiatives into the main branch and ship this as "pg-jdbc4.jar" or similar.
3. Where we have a "custom" driver (say Kevin Wooten's high performance
driver) where the driver is either not fully specification compliant, or
customised in some other manner, we keep as a separate codebase and ship
as "pg-jdbc?-????,jar". In time, where feasible, fold the code into the
main branch.

I see no problem in shipping multiple JAR libraries as several
commercial JDBC vendors are already doing this. We make them all
available with recommendations for stability being to use the "stable"
driver. If you want to try and experiment with one of the other drivers,
you can do so, we just need to document in the release the known issues
and differences to the stable driver. Environments like IBM WebSphere
support sand-boxing drivers within an application, so having multiple
driver versions loaded into a single JEE App Server is not an issue. If
you simply dump the driver into the "global" library, you get all you
deserve IMHO.

As I said, just my personal view on things.

On 26/06/13 23:51, Steven Schlansker wrote:
> On Jun 26, 2013, at 3:29 PM, "Marc G. Fournier" <scrappy@hub.org> wrote:
>
>>> How about, when Kevin's driver is ready:
>>>     • recommending the existing driver for JDBC3 and earlier
>>>     • and Kevin's driver for JDBC4 and greater?
>> Why not just create a 'pre-JDBC4 branch for the current official one and import Kevin's as JDBC4, for going forward?
What I've read seems to indicate a reluctance to make a whole whack of changes on the current code, so putting it over
toa branch shouldn't cause to much angst, should it? 
> Because currently the fork has zero adoption and no momentum, whereas the existing driver has a huge install base of
peoplewho expect to continue to receive updates going forward. 
>
> Not that it couldn't ever be the main branch, but I think you guys are jumping the gun by a lot.  And I'm even a fan
ofdoing the cool new shiny stuff. 
>
> The existing driver is tried and true, and I think for a project of PG-JDBC's stature it's going to take a lot more
thanan alpha driver codebase to switch the project over like that. 
>
>
>
>

> 1. Stability has to be top priority. I say this on the basis that every
> month that goes by, more and more organisations are either evaluating or
> making a switch away from proprietary databases and onto PostgreSQL. A
> great many of these are Java shops using some form of server environment
> such as Tomcat, Glassfish, WebSphere etc., so access will normally be
> via the JDBC Driver. To de-stabilise the existing driver in any way,
> shape or form, has the potential to de-rail the adoption of PostgreSQL
> in a big, big way. Do not do it!

That's why you promote the existing driver as the 'stable' driver, and
start development on a new code base.

> 2. To say that anything prior to Java7 is "dead" is ridiculous at this
> point in time, at least in a commercial environment. In one or two
> year's time however it may be different.

Which is likely the time frame to get a new driver code base up to
snuff, tested, and deemed stable.

> Yes, there may be compelling
> security reasons to upgrade from 6 to 7, but in an existing deployed
> commercial environment happily running Java 5 or 6, you are only going
> to upgrade to Java 7 if there is a very good reason to do so. I can
> recall numerous examples of a "simple" Java version upgrade breaking one
> or more production systems. I've just checked the very latest WebShere
> offering from IBM (Version 8.5.5) and that still installs Java6 by default.

Ok, so use the current driver, and let someone develop a newer one.

> 3. Yes, the current driver is not perfect, and there are several missing
> features which most people have identified as being more than just a
> nice to have.

Current users don't have to upgrade to a newer driver. The great thing
about software (and computers) is that they always do exactly what they
did the day you first started using them.

> In particular the work on getting XA support working
> correctly by Bryan Varner is something that will certainly help with
> installations running high transaction rate Glassfish or WebSphere
> installations and using the XA mode driver is a requirement.

It wasn't just me. Adam Gray and Kirk Winters also helped out immensely
with planning, review, testing, and code contributions. Thank POLARIS
Laboratories, not me.

> The big
> question is how do we get these new features and major fixes into the
> current driver without risk of destabilisation?

Why bother? If the current driver works for most people they can keep
using it.



As an aside, I think it's interesting that the longer this thread goes,
the more it proves the point that it's easier to just go do it yourself.

Regards,
-Bryan Varner

I'm trying to understand how changing the version number of the driver would affect all of the current users.

There are quite a few people using the driver and suddenly moving it seems precipitous 

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Mon, Jun 24, 2013 at 5:44 PM, John Lister <john.lister@kickstone.com> wrote:

I mentioned it in my previous post, but what are the lists thoughts on using a different versioning strategy for the driver in a similar manner to other OS projects.

My suggestion would be to:
- freeze the current release at v1.x for partial JDBC4 support
- archive the pre JDBC4 versions completely
- start a new version 2, for example incorporating the major NIO and XA changes previously discussed running on the current JDK incorporating stubs or complete functions for the latest JDBC spec features as needed, etc and supporting the latest versions of Postgres as appropriate

Work would progress with v2 with only significant bug fixes to then be propagated back to v1.

Hopefully this reaches some compromise for the stability issues with existing users who can remain on v1 with newer projects migrating to the v2.

At some point in the future I'd envisage a new version being released for example with the release of JDK8 or JDBC5 as required..

John

Hi Dave,

On 27/06/13 14:30, Dave Cramer wrote:
> I am coming to the conclusion that I should let new blood take over the
> postgresql driver. My lack of personal resources seems to be standing in
> the way of significant progress.
>
> Anyone interested in taking this on ?
>

I'm happy to help in this but might I suggest that rather than a single
individual take over that we get a group together? From the discussions
and list activity over the last little while I think there are a few
candidates but I do not wish to volunteer anyone for fear of missing and
offending people. Unless you really wish to step away from the JDBC, I'd
suggest you retain leadership and if you do wish to depart I'd ask that
you stay around and assist us in the transition.

The recurring plan that seems to be developing is to maintain the
current driver focusing on it's stability and compatibility. Going
forward the energy and focus would be towards a new driver which is
liberated from the concerns of backwards compatibility. Both sides of
the recent discussion have merits. Having recently moved on from an
employer where stability is king I was dealing with JDK 3 on occasion.
Incidentally, part of why I have moved on is that I do wish to do new
things!

Having already volunteered to work on getting the existing driver into
Maven I see the easiest way is to introduce two new artifact IDs.
Currently the artifact ID is simply postgresql but there is no reason we
couldn't use 'stable' and 'experimental' (experimental is the best I
could come up with off the top of my head!).

Long term we'll have to see whether we want to maintain two codebases.
For now let's experiment and see how things progress. There are pros and
cons to both codebases, neither are perfect. With that in mind this is
open source and people are free to do their own thing but there is
strength in numbers. We obviously all care about PostgreSQL and it's
JDBC driver so let us all try and make the best JDBC driver(s) possible!

Kind regards,
--
Mike Fowler
Registered Linux user: 379787

Dave the way this is going I do not think the main group supporting the
existing stable driver wish you to go. You appear to be the only one left
to provide input on the past knowledge base in its development. If you
wish to quit, I guess you can but perhaps some reorganization and some
help with the existing backlog of patches the current driver will be
supported by experience and be maintained.

The idea of having two versions allow the best of both new and old to
exist together. The old will be maintained and gradually require less
support. The new can be led by the group that have the passion to push
things forward.

I can not say for sure, but the thought of merging both a V1 & V2 in the
future would not be possible without a lot of work and coordination. Its
probably not worth it.

What should be done and a redesigned website can help facilitate this is
the bringing in the new V2 into the fold as the official standard for
Postgresql at some point in time. That may not occur for sometime as
indicated in the discussion.

danap.


Dave Cramer wrote:
> I am coming to the conclusion that I should let new blood take over the
> postgresql driver. My lack of personal resources seems to be standing in
> the way of significant progress.
>
> Anyone interested in taking this on ?
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca

I think if you're looking to differentiate in the maven naming, you'd probably want to use a qualifier instead of
changingthe artifact id.  Using the qualifier, you can leave the stable driver as is and only add an "experimental"
qualifierto the unstable new builds. 
________________________________________
From: pgsql-jdbc-owner@postgresql.org [pgsql-jdbc-owner@postgresql.org] on behalf of Mike Fowler [mike@mlfowler.com]
Sent: Thursday, June 27, 2013 10:20 AM
To: Dave Cramer
Cc: Bryan Varner; List
Subject: Re: [JDBC] JDBC 4 Compliance

Hi Dave,

On 27/06/13 14:30, Dave Cramer wrote:
> I am coming to the conclusion that I should let new blood take over the
> postgresql driver. My lack of personal resources seems to be standing in
> the way of significant progress.
>
> Anyone interested in taking this on ?
>

I'm happy to help in this but might I suggest that rather than a single
individual take over that we get a group together? From the discussions
and list activity over the last little while I think there are a few
candidates but I do not wish to volunteer anyone for fear of missing and
offending people. Unless you really wish to step away from the JDBC, I'd
suggest you retain leadership and if you do wish to depart I'd ask that
you stay around and assist us in the transition.

The recurring plan that seems to be developing is to maintain the
current driver focusing on it's stability and compatibility. Going
forward the energy and focus would be towards a new driver which is
liberated from the concerns of backwards compatibility. Both sides of
the recent discussion have merits. Having recently moved on from an
employer where stability is king I was dealing with JDK 3 on occasion.
Incidentally, part of why I have moved on is that I do wish to do new
things!

Having already volunteered to work on getting the existing driver into
Maven I see the easiest way is to introduce two new artifact IDs.
Currently the artifact ID is simply postgresql but there is no reason we
couldn't use 'stable' and 'experimental' (experimental is the best I
could come up with off the top of my head!).

Long term we'll have to see whether we want to maintain two codebases.
For now let's experiment and see how things progress. There are pros and
cons to both codebases, neither are perfect. With that in mind this is
open source and people are free to do their own thing but there is
strength in numbers. We obviously all care about PostgreSQL and it's
JDBC driver so let us all try and make the best JDBC driver(s) possible!

Kind regards,
--
Mike Fowler
Registered Linux user: 379787


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

> Long term we'll have to see whether we want to maintain two codebases.
> For now let's experiment and see how things progress. There are pros and
> cons to both codebases, neither are perfect. With that in mind this is
> open source and people are free to do their own thing but there is
> strength in numbers. We obviously all care about PostgreSQL and it's
> JDBC driver so let us all try and make the best JDBC driver(s) possible!

+1

Very well put, Mike.

Mike Fowler-3 wrote
> Long term we'll have to see whether we want to maintain two codebases.
> For now let's experiment and see how things progress. There are pros and
> cons to both codebases, neither are perfect. With that in mind this is
> open source and people are free to do their own thing but there is
> strength in numbers. We obviously all care about PostgreSQL and it's
> JDBC driver so let us all try and make the best JDBC driver(s) possible!


Slightly tangential but to what degree is adhering to JDBC limiting our
ability to fully explore the power of the PostgreSQL database?

One example that comes to mind is that because "?" is the JDBC placeholder,
as opposed to ":var_name" in the native C library, it is (AFAICS) impossible
to write a query that uses "?" as an operator.  Dollar-Quoting issues also
come to mind.

Is it possible to have a "true PostgreSQL driver" with a "JDBC wrapper".  I
get you can access the raw implementation instead of using JDBC interfaces
but are there things being internally that could be done different if using
a layered approach?

David J.




--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5761441.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

I've phrased this before but I'm of the mind to avoid "stable" and
"experimental" references.  I imagine a scenario where there is no
"official" driver but simply "blessed" drivers.  Blessed drivers have been
reviewed by the PostgreSQL JDBC team for functionality, performance, and
stability and have had a comparison/review done and published.  There might
be two or three experimental drivers in the wild at any given time that have
chosen different trade-offs.  In many ways similar to how Linux and Distros
inter-operate though the core is spec and not necessarily a shared codebase.
But whereas Linux doesn't really care about the Distros the PostgreSQL JDBC
team would indeed try to care about the different implementations that are
in the wild.

David J.


Adam Gray wrote
> I think if you're looking to differentiate in the maven naming, you'd
> probably want to use a qualifier instead of changing the artifact id.
> Using the qualifier, you can leave the stable driver as is and only add an
> "experimental" qualifier to the unstable new builds.
>
> Having already volunteered to work on getting the existing driver into
> Maven I see the easiest way is to introduce two new artifact IDs.
> Currently the artifact ID is simply postgresql but there is no reason we
> couldn't use 'stable' and 'experimental' (experimental is the best I
> could come up with off the top of my head!).





--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5761450.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

Bryan Varner wrote
> As an aside, I think it's interesting that the longer this thread goes,
> the more it proves the point that it's easier to just go do it yourself.

Define "it".  What specifically is easier to accomplish on your own?  What
goals and restrictions are you setting for re-inventing the wheel?  How much
of the existing work are you going to simply copy?

The thing bothering you right now is politics which, by broad definition, is
the resolving of differences between individuals.  Of course "do[ing] it
yourself" is going to resolve the political issues since there is no more
"between individuals" aspect to deal with anymore.  It is also a big cop-out
from the perspective of the pre-existing community.  Sure, go off on your
own and when you come back in a couple of years maybe what you did will be
what we need/want - but since you weren't interacting with us in the
meantime who knows.  Maybe you don't care if it works for anyone else but
yourself and a few others who happen to stumble upon it (and would simply be
thrilled if indeed it becomes the new standard somehow) and while that isn't
necessarily a bad/wrong position to take it is by some definitions selfish;
and regardless is anathema to those, like Dave, who because of the community
focus cannot simply throw everything away and start fresh; and definitely
doesn't want to make things easier by taking the politics out of the
process.  Since "transition" is necessary so are the politics.  And its
better to get that out of the way now since politics can influence
technology but seldom does it work the other way around.

David J.








--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5761470.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

I don't think this has anything to do with Dave's amount of time, and I
think he's done a remarkable job of keeping the lights on.

>> As an aside, I think it's interesting that the longer this thread goes,
>> the more it proves the point that it's easier to just go do it yourself.
>
> Define "it".  What specifically is easier to accomplish on your own?

Ok. I'll bite. I'll answer your questions wrt adding a second XA
implementation.

* It's easier to modify the driver to fit your needs and work with your
own git repository than it is to push the change upstream.

* There's little need to push the change up stream because face it,
there's not much action going on in the upstream repository.

* Since there's no action in the upstream repo, the cost of merging
upstream remotes is lower than the cost of prepping a branch for a pull
request.

> What goals and restrictions are you setting for re-inventing the wheel?

I needed PostgreSQL to be a stable JDBC XADataSource in GlassFish 3.1,
where I can't turn interleaving off in the transaction manager.

> How much of the existing work are you going to simply copy?

Pretty much just the method signatures...

> The thing bothering you right now is politics which, by broad definition, is
> the resolving of differences between individuals.

How bold (and incorrect) of you to assume you know what's bothering me.

> Of course "do[ing] it
> yourself" is going to resolve the political issues since there is no more
> "between individuals" aspect to deal with anymore.  It is also a big cop-out
> from the perspective of the pre-existing community.  Sure, go off on your
> own and when you come back in a couple of years maybe what you did will be
> what we need/want - but since you weren't interacting with us in the
> meantime who knows.

I sure hope you weren't directing that at me. I (and others in my
office) have willingly debated, implemented, and jumped through the
required hoops to get an interleaving-capable XA implementation merged
into the mainline driver. We're quite pleased with the results. Thanks
to the debate on the list, the implementation was able to rapidly mature
and improve. It's been stable (on glassfish 3.1.2.2) for us for several
months now, and we have the community on this list to thank for
challenging our initial ideas.

It would have been *far* easier for us to maintain a downstream branch
on github with our implementation rather than try to push it upstream.

I don't want to see this project fragment. I believe it would benefit
the community to have a confluence around a central project with a
structure to coordinate and accept things which progress the status quo.

>  Maybe you don't care if it works for anyone else but
> yourself and a few others who happen to stumble upon it (and would simply be
> thrilled if indeed it becomes the new standard somehow) and while that isn't
> necessarily a bad/wrong position to take it is by some definitions selfish;
> and regardless is anathema to those, like Dave, who because of the community
> focus cannot simply throw everything away and start fresh; and definitely
> doesn't want to make things easier by taking the politics out of the
> process.

I do care, a lot. That's why I'm still here, and that's why I've created
pull requests to get our changes up stream. I want other people to be
able to benefit from our work, and I'd like (on a personal level) to be
able to continue contributing to the success of pg in the enterprise
markets.

I have had conversations with developers from other large FOSS projects
who would love to advocate more postgresql adoption but are hesitant to
do so based upon the 'stagnant' perception they have of the driver. Most
of their concerns focus on lacking implementations or issues with jdbc
4.x and blobs.

> Since "transition" is necessary so are the politics.

Bull.

What's bothering me is not politics. What's bothering me is the giant
vacuum of direction. There is no long-term goal. There's no plan to EOL
or sunset support for specific combinations of systems. There's no
structure or path for incorporating new ideas, new talent, or new
features into the project.

The defacto leader right now is Dave, and his calls for action have come
up empty handed so far. There's been calls to create a managing 'board'
(for lack of better words) to manage the political process, and so far,
no one has actually *done* anything. It's the lack of action, on all
accounts, which is truly bothering me.

The 'politics' as you put it are just window dressing. In reality none
of us need to sit here and put up with it. We just need one person
(anyone) who has the guts to say, "Let's go", draft a project charter,
fork the repo, and be done with this. The existing driver can sit here
and rot in 'maintenance' mode.

I think what everyone is waiting for is for Dave to say, Ok, let's do
this (and describe a plan). Instead, what we got was (heavily
paraphrased) 'I don't have time for this who wants to inherit the mess?'
I don't blame him, and I sure didn't volunteer. This is a consequence of
not having a managing board or road-map.

FOSS projects never really die. They just fade into irrelevance.

Regards,
-Bryan Varner

Bryan Varner wrote
>> Since "transition" is necessary so are the politics.
>
> Bull.
>
> What's bothering me is not politics. What's bothering me is the giant
> vacuum of direction. There is no long-term goal. There's no plan to EOL
> or sunset support for specific combinations of systems. There's no
> structure or path for incorporating new ideas, new talent, or new
> features into the project.
>
> The defacto leader right now is Dave, and his calls for action have come
> up empty handed so far. There's been calls to create a managing 'board'
> (for lack of better words) to manage the political process, and so far,
> no one has actually *done* anything. It's the lack of action, on all
> accounts, which is truly bothering me.

My general thoughts stand; I'll leave it to individuals to decide to what
extent my thoughts may apply to them.  I do not know any persons or projects
well enough to point fingers; my thoughts are much more theoretical in
nature.

Also, I would classify being bothered by a lack of direction to be bothered
by something political.  Maybe its semantics but that is where I am coming
from.

I have lots of ideas, as I am sure others do, but I am not being pressed
currently and have other aspects of my own house to get in order before I
could follow-through along this front.  I too hope someone can take the ball
and run and move this discussion off of a single e-mail thread and into some
more structured.

David J.






--
View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5761492.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

On 2013-06-27, at 05:45 , Andrew Hastie <andrew@ahastie.net> wrote:

> 2. To say that anything prior to Java7 is "dead" is ridiculous at this point in time, at least in a commercial
environment.In one or two year's time however it may be different. Yes, there may be compelling security reasons to
upgradefrom 6 to 7, but in an existing deployed commercial environment happily running Java 5 or 6, you are only going
toupgrade to Java 7 if there is a very good reason to do so. I can recall numerous examples of a "simple" Java version
upgradebreaking one or more production systems. I've just checked the very latest WebShere offering from IBM (Version
8.5.5)and that still installs Java6 by default. 

Stupid question, but in an "existing deployed commercial environment happily running Java 5 or 6", are they going to be
upgradingtheir JDBC more frequently then their JDK?   basically, "if it ain't broke, don't fix it" applies to their
JDK,won't it apply to there jDBC too?    

On Jun 27, 2013, at 7:48 AM, David Johnston <polobo@yahoo.com> wrote:

> Mike Fowler-3 wrote
>> Long term we'll have to see whether we want to maintain two codebases.
>> For now let's experiment and see how things progress. There are pros and
>> cons to both codebases, neither are perfect. With that in mind this is
>> open source and people are free to do their own thing but there is
>> strength in numbers. We obviously all care about PostgreSQL and it's
>> JDBC driver so let us all try and make the best JDBC driver(s) possible!
>
>
> Slightly tangential but to what degree is adhering to JDBC limiting our
> ability to fully explore the power of the PostgreSQL database?
>
> One example that comes to mind is that because "?" is the JDBC placeholder,
> as opposed to ":var_name" in the native C library, it is (AFAICS) impossible
> to write a query that uses "?" as an operator.  Dollar-Quoting issues also
> come to mind.
>
> Is it possible to have a "true PostgreSQL driver" with a "JDBC wrapper".  I
> get you can access the raw implementation instead of using JDBC interfaces
> but are there things being internally that could be done different if using
> a layered approach?

My new codebase is structured exactly this way.  There is a PostgreSQL driver and a comfortably fitting JDBC layer on
topof it.  One could take the driver itself define a new API  and use it that way if they wished. 

Although, the example you give is probably very easily handled as an extension through the JDBC layer (just provide and
escapesyntax like ??).  It's interesting to note that SQL itself says the ? is sacred and only to be used as a
parameterplaceholder. 

>
> David J.
>
>
>
>
> --
> View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5761441.html
> Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc

On 28/06/13 01:30, Dave Cramer wrote:
> I am coming to the conclusion that I should let new blood take over
> the postgresql driver. My lack of personal resources seems to be
> standing in the way of significant progress.
>
> Anyone interested in taking this on ?
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
[...]
I greatly appreciate the work you have done.

Also I agree what others are saying, please stay on - at least as a
leader or mentor.  There is a clear need for your driver going forward,
as stability and reliability are paramount.  Plus, even if Kevin's
driver suddenly was fully featured, it will take a while for it to
become sufficiently reliable as yours, and even longer for conservative
corporates to accept that.

It would be great if funding could be got for you to work full time on
JDBC drivers: yours for maintenance & some new features where
appropriate/feasible, and to help Kevin's driver development with your
depth of practical experience.  If wishes were horses...


Cheers,
Gavin

Kevin,

I haven't been paying close attention to the details; can you list what
the differences from a user's point of view are between your driver and
the official one? What features is the official driver missing that
you've implemented? I'd be interested in taking a closer look at them,
to see what it would take to implement those in the official driver,
with help from the code from your driver.

- Heikki

When this somewhat settles out. I'm still open to helping with the web page.
Provied that I can help to contribute in that way with providing a more effect
means to communication todo list, patches/tracking, gap analysis, etc.

Without a means for people to easily understand specific areas to contribute
with direction, and perhaps individual(s) to contact for each area I think the
project is going to continue to be lacking in direction and momentum.

danap.
Dana M. Proctor
MyJSQLView Project Manager

Dave Cramer wrote:
> Tom,
>
> The test suite is not bad, but it certainly could use more tests. I
> doubt it confirms everything.
>
> Plus there are some things you can only test in production
>
>
> On a more general note. After today I will be away from my computer for
> the next 3 days.
> I am going to contemplate my involvement, which at this time is leaning
> towards staying on and developing a team to which I will feel
> comfortable leaving the driver to.
>
> There's been considerable talk about not supporting 4.1, blobs, etc. I'd
> like to understand what is missing; I've asked this before does anyone
> have a gap analysis ?
>
>
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Thu, Jun 27, 2013 at 11:43 PM, Tom Dunstan <pgsql@tomd.cc
> <mailto:pgsql@tomd.cc>> wrote:
>
>     On 27 June 2013 23:50, Mike Fowler <mike@mlfowler.com
>     <mailto:mike@mlfowler.com>> wrote:
>
>         The recurring plan that seems to be developing is to maintain
>         the current driver focusing on it's stability and compatibility.
>         Going forward the energy and focus would be towards a new driver
>         which is liberated from the concerns of backwards compatibility.
>
>
>     Uh, what? Which backwards compatibility were you intending to throw
>     away? Just older JRE versions?
>
>         Long term we'll have to see whether we want to maintain two
>         codebases. For now let's experiment and see how things progress.
>         There are pros and cons to both codebases, neither are perfect.
>         With that in mind this is open source and people are free to do
>         their own thing but there is strength in numbers. We obviously
>         all care about PostgreSQL and it's JDBC driver so let us all try
>         and make the best JDBC driver(s) possible!
>
>
>     As a long-time user of the driver, I'd like to de-lurk to point out
>     that the nervousness about stability which has surfaced in this
>     thread (and which I share) can often point to opportunities to
>     improve automated test coverage.
>
>     Dave, how complete would you say that the existing test suites are?
>     If a new implementation can pass the tests, how much does that say
>     about the driver's completeness or backwards compatibility?
>
>     And for those who have forked the driver or started from scratch, do
>     you have comments on the existing test suite? Or have you written
>     your own?
>
>     If the AIO etc driver is to be developed in parallel with the
>     existing one, it might be an interesting idea to split the tests out
>     into a separate project so that the tests can be run against both
>     drivers. Then improvements in the test suite are shared as well!
>
>     Cheers
>
>     Tom

https://github.com/pgjdbc/pgjdbc/pull/67

I made a minor comment / suggestion for improvement, once that is handled I vote to merge this.



https://github.com/pgjdbc/pgjdbc/pull/35

There's some legitimate concern that fixing these spelling errors will cause breakage in people who check the literal
exceptionstring, however the messages they are in are relatively uncommon / mostly unrecoverable errors anyway (i.e.
it'snot like we are trying to change "A foreign key was violated" or something that people might actually look at).  So
Ivote to merge. 


https://github.com/pgjdbc/pgjdbc/pull/5

Looks like this one is waiting on a flag to change between old / new behavior?


https://github.com/pgjdbc/pgjdbc/pull/54

Has anyone that has the proper OSS credentials tested this?  I think this just needs someone with OSS credentials to
testit, and then it could be merged.  Who has the appropriate credentials? 



https://github.com/pgjdbc/pgjdbc/pull/51

Fails build, not ready to merge.




In summary, I think there are two PRs that should be merged soon (maybe after some minor fixups) and one that is
blockedon someone with OSS credentials to test. 

Two more require somewhat more work.

Hope this is a helpful "clean up" of open PRs.


On Jun 26, 2013, at 12:19 PM, Dave Cramer <pg@fastcrypt.com> wrote:

> OK, so at this point we need some todo's
>
> I'd like to see what we can do with java 4.1 compatibility
>
> We need to clean up the outstanding pull requests.
>
>
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Wed, Jun 26, 2013 at 3:09 PM, Steven Schlansker <stevenschlansker@gmail.com> wrote:
>
> On Jun 26, 2013, at 11:58 AM, Dave Cramer <pg@fastcrypt.com> wrote:
>
> > Currently I am the only committer, (Kris is still but he's not active now) I would remain that way for a while til
Isee where this is going. 
> >
> > Dana , have a look at http://jekyllrb.com/
> >
> > As for other people who have offered help Stephen Nelson has shown some interest.
> >
>
> First, thanks so much for your (and Kris's, and all the other committers') hard work.  It is appreciated!  The
PostgresJDBC driver has been stable and reliable and a core part of a lot of the projects I currently work on. 
>
> It sounds like at this point, even if the decision is to stay with the current mainline for the time being, the
projectneeds some "new blood" to ensure it keeps going in the case where you lose the interest or time to donate to the
project.
>
> I would happily donate some time to doing code review and implementing improvements.
>
> Maybe you (or everyone as a group?) should draw up some guidelines on what sort of expectations there are of
committers. I could see introducing ten new committers to help with code review all at the same time causing a lot of
instabilityboth in the driver and the project, unless everyone agrees on what are / aren't the goals of the current
JDBCdriver.  I think "not destabilizing the current driver" is a worthy priority, given how many people depend on it… 
>
>
>

-1 for qualifiers. You will have problems deploying java docs/sources for two versions under single artifact name.

On Jun 28, 2013, at 4:53 PM, Steven Schlansker <stevenschlansker@gmail.com> wrote:

> https://github.com/pgjdbc/pgjdbc/pull/67
>
> I made a minor comment / suggestion for improvement, once that is handled I vote to merge this.

I followed up with the committer and now I think the patch is ready to merge.

> <snip rest of PRs>