Skip site navigation (1) Skip section navigation (2)

Re: Result Set Cursor Patch

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Result Set Cursor Patch
Date: 2004-05-05 23:06:57
Message-ID: 40997391.20301@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Kris Jurka wrote:

> The formatting is an issue.  Yes, the code is formatted differently all 
> over the driver, but now is not the time to fix that.  There are too many 
> outstanding patches that will conflict with these whitespace changes to 
> try and do something about that now.  I aim to reindent/reformat at the 
> start of 7.5 beta when there shouldn't be many outstanding patches or 
> active development.

Are we still tracking the main tree's release cycle then? I thought part 
of the reason for moving to gborg was because the JDBC driver's release 
cycle didn't match the main tree's release cycle well?

I have a large stack of not-yet-ready-for-prime-time v3 protocol changes 
that I'd like to get in at some point -- but I don't want to get bitten 
by "we're in beta, this is too big to apply". Are we planning on a 
code/feature freeze or similar, tracking whatever 7.5 is doing?

Also, now that the driver is separate from the main code tree, maybe 
it'd be a good idea when reindenting to use more "normal" (for java 
anyway) indentation rules -- e.g. use either all spaces or spaces and 
8-character tabs when indenting. The current 4-character tabs rule is 
fairly unusual. That'd make driver editing easier across a range of 
IDEs; sure, I have my xemacs settings that play nicely with the current 
scheme, but it's a barrier to entry for anyone who hasn't worked on the 
driver before.

-O

In response to

Responses

pgsql-jdbc by date

Next:From: Brian OlsonDate: 2004-05-05 23:55:14
Subject: Re: Result Set Cursor Patch
Previous:From: Andy ZeneskiDate: 2004-05-05 21:04:13
Subject: Re: Result Set Cursor Patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group