Thread: Re: [INTERFACES] problem with JDBC

    I don't know the answer, but I'll tell you that if you don't get an
answer here, there is a newsgroup at comp.lang.java.databases that should
be able to help you.


At 04:22 PM 6/2/99 +0800, ßN·¬ wrote:
>I have a problem with JDBC:
>I write an applet including the JDBC code to connect to the pgsql server
>to get data.
>My applet runs fine everytime from the init() state.
>But sometimes goes wrong if I press "Reload" on the browser which makes
>my program runs again from the start() state.
>The Statement gets the previous ResultSet to me when I
>"executeQuery(SQLQuery)".
>Is that possible that I get the previous ResultSet because I press the
>"Reload" while the ResultSet is transferring to me ?
>But the document says that the previous ResultSet will be close by the
>Statement when that statement is re-executed .
>Therefore, why do I get the previous ResultSet in the Statement ?
>

Thomas,

Has anyone taken the time to apply the unixODBC changes to the PostgreSQL
ODBC driver. I ask because I would like to email a couple of more changes
but it would only make sense if the previous changes have been applied.

Peter Harvey

BTW: You guys should consider giving out cvs write access for those of us
that do not do patch submissions... anyway; current set of changes are tiny
so I will email them if you want them (they are based upon the previous,
wide spread changes I made earlier). Otherwise we are heading down the road
of a code fork <groan>.

> Has anyone taken the time to apply the unixODBC changes to the 
> PostgreSQL ODBC driver. I ask because I would like to email a couple 
> of more changes but it would only make sense if the previous changes 
> have been applied.

Not that I know of. We have been busy preparing for a release and do
not have time to chase around your proposed changes. Someone might
have time later.

> BTW: You guys should consider giving out cvs write access for those of 
> us that do not do patch submissions... anyway; current set of changes 
> are tiny so I will email them if you want them (they are based upon 
> the previous, wide spread changes I made earlier). Otherwise we are 
> heading down the road of a code fork <groan>.

Well, "those of us that do not do patch submissions" end up not
contributing much code! We have a relatively small group of folks
privileged to make direct cvs updates, and they have been given that
privilege after working with the code and submitting patches for an
extended period of time.

Byron is the keeper of the ODBC code, and in fact does his work
outside of the Postgres source tree since his development target is
WIN32. The last time I looked the unixODBC drivers were claiming alpha
or beta status, and it seemed a bit early to jump on integrating that
code base into the Postgres production tree.

I support your goal of avoiding a code fork, but imho you will need to
do a bit of work to: 1) send your changes, rather than sending a URL;
2) explain your changes if they are not small, self-evident patches;
3) work with Byron to ensure that the changes are compatible with his
code and the direction it is taking.

Regards.
                   - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California

> Byron is the keeper of the ODBC code, and in fact does his work
> outside of the Postgres source tree since his development target is
> WIN32. The last time I looked the unixODBC drivers were claiming alpha
> or beta status, and it seemed a bit early to jump on integrating that
> code base into the Postgres production tree.

Clarification; some unixODBC components are Beta, a few are even Alpha, but
most is Beta... including the PostgreSQL driver. Remember; the PostgreSQL
driver in unixODBC is Byrons driver with some enhancements.

>
> I support your goal of avoiding a code fork, but imho you will need to
> do a bit of work to: 1) send your changes, rather than sending a URL;
> 2) explain your changes if they are not small, self-evident patches;
> 3) work with Byron to ensure that the changes are compatible with his
> code and the direction it is taking.

Ok. I will email a gz file with all changes and an explanation (to Thomas).
Please take the time to apply the changes. These changes are mostly for
making PostgreSQL work with StarOffice.

Thanks!

Peter Harvey

On Wed, 2 Jun 1999, Peter Harvey wrote:

> > Byron is the keeper of the ODBC code, and in fact does his work
> > outside of the Postgres source tree since his development target is
> > WIN32. The last time I looked the unixODBC drivers were claiming alpha
> > or beta status, and it seemed a bit early to jump on integrating that
> > code base into the Postgres production tree.
> 
> Clarification; some unixODBC components are Beta, a few are even Alpha, but
> most is Beta... including the PostgreSQL driver. Remember; the PostgreSQL
> driver in unixODBC is Byrons driver with some enhancements.
> 
> >
> > I support your goal of avoiding a code fork, but imho you will need to
> > do a bit of work to: 1) send your changes, rather than sending a URL;
> > 2) explain your changes if they are not small, self-evident patches;
> > 3) work with Byron to ensure that the changes are compatible with his
> > code and the direction it is taking.
> 
> Ok. I will email a gz file with all changes and an explanation (to Thomas).
> Please take the time to apply the changes. These changes are mostly for
> making PostgreSQL work with StarOffice.

*scratch head*  the proper method of submitting *any* changes is to send a
patch file to the maintainer of that area of the code, in this
case...Byron, not Thomas.  Thomas is involved in *alot* of things, whereas
Byron is dedicated to the ODBC code...

Even better is to send a copy of the patch to pgsql-patches *and* the
maintainer, just in case the maintainer is away ...

Note that a .gz file (assuming its a replacement of files, vs just a
compressed patch) is, IMHO, *not* acceptable, since it becomes hellish to
review before inclusion...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org