Re: Solaris getopt_long and PostgreSQL - Mailing list pgsql-hackers

From Zdenek Kotala
Subject Re: Solaris getopt_long and PostgreSQL
Date
Msg-id 1238999336.1387.7.camel@localhost
Whole thread Raw
In response to Re: Solaris getopt_long and PostgreSQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane píše v ne 05. 04. 2009 v 17:44 -0400:
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> > Zdenek Kotala píše v út 31. 03. 2009 v 21:25 +0200:
> >> Another possibility is to rewrite postgres(and pg_resetxlog) to use
> >> getopt_long() instead of getopt().
> 
> > Attached patch rewrites postgres to use getopt_long instead of getopt.
> 
> Actually, I fooled around with it last night and seem to have fixed it
> (buildfarm is all green today) by the expedient of not defining our own
> optind etc. variables if the system supplies them.  So that seemed like
> a clean fix to me --- the old handling of optreset in particular was a
> huge kluge, whereas it's clear how this code is supposed to work.

Yeah, everything is green today. Thanks. Is it possible to backport it
at least to 8.3?

> I don't think we need to mess around with changing our option parsing
> logic, especially not to the extent that you propose here.

When previous solution works well on all platforms there is no reason to
use getopt_long.
Thanks Zdenek



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Next
From: higepon
Date:
Subject: Auto-delete large objects when referencing row is deleted