Re: [HACKERS] [PATCHES] Adding a --quiet option to initdb

2006-01-25 Thread Devrim GUNDUZ
Hi,

On Wed, 2006-01-25 at 16:32 +0100, Peter Eisentraut wrote:

> > I think a command line options is better and required.
> 
> I think we need more proof of that than a use case involving taking 
> screen shots.

I've just explained my points as a reply to Tom's mail.

Regards,
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] [PATCHES] Adding a --quiet option to initdb

2006-01-25 Thread Bruce Momjian
Peter Eisentraut wrote:
> Devrim GUNDUZ wrote:
> > We have the same options with reindexdb, for example.
> 
> reindexdb and friends inherited that option from psql.  On a green 
> field, they probably wouldn't have it.  psql has more complex 
> semantics, so it's not clear whether that's the same thing.
> 
> > I think a command line options is better and required.
> 
> I think we need more proof of that than a use case involving taking 
> screen shots.

Agreed on both points.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  pgman@candle.pha.pa.us   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [PATCHES] Adding a --quiet option to initdb

2006-01-25 Thread Peter Eisentraut
Devrim GUNDUZ wrote:
> We have the same options with reindexdb, for example.

reindexdb and friends inherited that option from psql.  On a green 
field, they probably wouldn't have it.  psql has more complex 
semantics, so it's not clear whether that's the same thing.

> I think a command line options is better and required.

I think we need more proof of that than a use case involving taking 
screen shots.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PATCHES] Adding a --quiet option to initdb

2006-01-25 Thread Devrim GUNDUZ
Hi,

On Wed, 2006-01-25 at 17:22 +0200, Devrim GUNDUZ wrote:
> On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
> > What's wrong with just sending stdout to /dev/null? If that eats
> error
> > messages too then we should probably fix initdb to send those to
> > stderr.
> 
> We have the same options with reindexdb, for example. I think a
> command
> line option 

(Opps...) We have the same options with reindexdb, for example. I think
a command line options is better and required.

Regards,
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] [PATCHES] Adding a --quiet option to initdb

2006-01-25 Thread Devrim GUNDUZ
Hi Andrew,

On Wed, 2006-01-25 at 09:28 -0500, Andrew Dunstan wrote:
> What's wrong with just sending stdout to /dev/null? If that eats error
> messages too then we should probably fix initdb to send those to
> stderr.

We have the same options with reindexdb, for example. I think a command
line option 

> But if we are going to do this, then I also noticed a couple of
> things:
> 
> . you should explicitly initialize the quiet variable, in keeping with
> the style of the others nearby.

Oh, I've missed it. Patch updated.

> . the idiom
> 
>if (! quiet) 
>{
>   fputs(_("some message"),stdout);
>   fflush(stdout);
>}
> 
> should not be endlessly repeated. Make it a macro or a function.

I'm looking at it now.

Thanks for your comments. I'll provide a new patch soon, which will also
include Alvaro's suggestion about surpression both header and footer 
(--make-initdb-really-quiet-mode :) )

Regards,
-- 
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] Adding a --quiet option to initdb

2006-01-25 Thread Andrew Dunstan
On Wed, 2006-01-25 at 16:08 +0200, Devrim GUNDUZ wrote:
> Hi,
> 
> Attached is a patch which adds --quiet and --q option to initdb. I
> personally needed this option while writing a document and taking
> screenshot :) It only shows the error and warning messages, as well as
> the last lines.
> 
> I've updated the docs. Regression tests pass.
> 
> This is my first patch to PostgreSQL source, so please guide me if I
> have done something wrong.
> 

Devrim,

What's wrong with just sending stdout to /dev/null? If that eats error
messages too then we should probably fix initdb to send those to stderr.

But if we are going to do this, then I also noticed a couple of things:

. you should explicitly initialize the quiet variable, in keeping with
the style of the others nearby.

. the idiom

   if (! quiet) 
   {
  fputs(_("some message"),stdout);
  fflush(stdout);
   }

should not be endlessly repeated. Make it a macro or a function.

I wonder if we can just set rid of all those fflush() calls by
unbuffering stdout with a single call to setbuf() or setvbuf()?



cheers

andrew




---(end of broadcast)---
TIP 6: explain analyze is your friend