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

Re: Result Set Cursor Patch

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Brian Olson <bolson(at)bolson(dot)org>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Result Set Cursor Patch
Date: 2004-05-07 00:43:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Brian Olson wrote:
> This outsider/new-guy-on-the-list thinks "4 space" tabs are great. I think
> it's very portable because if a file is indented with all tabs then
> someone can set their editor to render that however they like: 2, 4, 8, e,
> Pi, etc. "spaces".

This only works if you only ever indent in strict multiples of a 
tabwidth and are consistent about only ever using tabs. In practice, 
this doesn't happen -- you'll get spaces appearing pretty fast. Witness 
the current driver, where in theory only tabs should be being used, but 
in practice there are lots of spaces used to indent. Also consider cases 
like this, assuming 2-space tabs on the lefthand side:

   if (condition) { // Comment 1
     code;          // Comment 2
   }                // Comment 3

With 4 space tabs we get:

     if (condition) { // Comment 1
         code;          // Comment 2
     }                // Comment 3

Oops, those comments don't nicely line up any more. You can't fix it 
using tabs to align the comments either, since the indenting you need on 
a particular line depends on the line length and isn't necessarily a 
multiple of the tab width.

> 4 space + 8-space-tabs is the least portable. Everyone has to configure
> their editor exactly alike.

Yes, mixing spaces and tabs makes life difficult (especially if you're 
editing python code!). This is essentially the same case as the current 
code (both spaces and 4-space-tabs are used, although tabs-only is 

> all spaces is portable, everyone gets the same thing, but on the down
> side, everyone gets the same thing.

This is what I prefer because it's hard to get wrong. And personally I 
think that the *goal* is that everyone sees the same thing for a 
particular bit of code.

And it makes 'diff' and 'less' produce more readable output, too :)

There's a pretty good summary of the issues at Some conclusions from that doc:

>  My opinion is that the best way to solve the technical issues is to
> mandate that the ASCII #9 TAB character never appear in disk files:
> program your editor to expand TABs to an appropriate number of spaces
> before writing the lines to disk. That simplifies matters greatly, by
> separating the technical issues of #2 and #3 from the religious issue of
> #1.

> I just care that two people editing the same file use the same
> interpretations, and that it's possible to look at a file and know what
> interpretation of the TAB character was used, because otherwise it's
> just impossible to read.


In response to

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2004-05-07 00:48:08
Subject: Re: Where is the JDBC driver source?
Previous:From: Carson GrossDate: 2004-05-06 18:26:49
Subject: Where is the JDBC driver source?

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