remove 'noversion' from standalone backend
This patch removes the remaining code for processing the '-C'
command-line option in the standalone backend. It no longer actually
functions (i.e. specifying the option does nothing), and I didn't
think it was interesting enough to be worth reviving, so I removed it.
Unless anyone objects, I intend to apply this in 24 hours or so.
-Neil
Attachments:
remove-no-version-2.patchtext/x-patchDownload
Index: src/backend/tcop/postgres.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/tcop/postgres.c,v
retrieving revision 1.381
diff -c -r1.381 postgres.c
*** src/backend/tcop/postgres.c 25 Dec 2003 03:52:51 -0000 1.381
--- src/backend/tcop/postgres.c 5 Jan 2004 20:59:31 -0000
***************
*** 2073,2079 ****
/*
* Set default values for command-line options.
*/
- Noversion = false;
EchoQuery = false;
if (!IsUnderPostmaster)
--- 2073,2078 ----
***************
*** 2104,2110 ****
ctx = debug_context = PGC_POSTMASTER;
gucsource = PGC_S_ARGV; /* initial switches came from command line */
! while ((flag = getopt(argc, argv, "A:B:c:CD:d:Eef:FiNOPo:p:S:st:v:W:x:-:")) != -1)
switch (flag)
{
case 'A':
--- 2103,2109 ----
ctx = debug_context = PGC_POSTMASTER;
gucsource = PGC_S_ARGV; /* initial switches came from command line */
! while ((flag = getopt(argc, argv, "A:B:c:D:d:Eef:FiNOPo:p:S:st:v:W:x:-:")) != -1)
switch (flag)
{
case 'A':
***************
*** 2125,2138 ****
SetConfigOption("shared_buffers", optarg, ctx, gucsource);
break;
- case 'C':
-
- /*
- * don't print version string
- */
- Noversion = true;
- break;
-
case 'D': /* PGDATA directory */
if (secure)
potential_DataDir = optarg;
--- 2124,2129 ----
Index: src/backend/utils/init/globals.c
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/init/globals.c,v
retrieving revision 1.76
diff -c -r1.76 globals.c
*** src/backend/utils/init/globals.c 29 Nov 2003 19:52:01 -0000 1.76
--- src/backend/utils/init/globals.c 5 Jan 2004 20:59:31 -0000
***************
*** 25,32 ****
ProtocolVersion FrontendProtocol = PG_PROTOCOL_LATEST;
- bool Noversion = false;
-
volatile bool InterruptPending = false;
volatile bool QueryCancelPending = false;
volatile bool ProcDiePending = false;
--- 25,30 ----
Index: src/include/miscadmin.h
===================================================================
RCS file: /var/lib/cvs/pgsql-server/src/include/miscadmin.h,v
retrieving revision 1.140
diff -c -r1.140 miscadmin.h
*** src/include/miscadmin.h 21 Dec 2003 04:34:35 -0000 1.140
--- src/include/miscadmin.h 5 Jan 2004 20:59:31 -0000
***************
*** 125,131 ****
extern bool ExitOnAnyError;
- extern bool Noversion;
extern char *DataDir;
extern DLLIMPORT int MyProcPid;
--- 125,130 ----
Neil Conway <neilc@samurai.com> writes:
Unless anyone objects, I intend to apply this in 24 hours or so.
Patch applied.
-Neil
P.S. BTW, how does everyone feel about the methodology I've been using
for submitting and applying patches? The procedure I'm following is:
- for trivial / obviously correct patches, just apply them immediately
- for fairly simple patches, submit them to the list and apply them
fairly soon afterward (say, within 24 hours or 48 hours). When I
apply the patch, send another mail to wrap up the issue.
- for more complex stuff, the usual submission & review process until
the patch is ready to be applied.
If people don't want the additional mail when a patch is applied, I
can stop sending those to reduce the quantity of mail on -patches. I'm
also open to any other suggestions for procedural changes...
(To hackers)
On Tue, Jan 06, 2004 at 01:06:17PM -0500, Neil Conway wrote:
P.S. BTW, how does everyone feel about the methodology I've been using
for submitting and applying patches? The procedure I'm following is:
The only thing I'd like is that the applied patch is attached in the
automatic mail sent to pgsql-committers (or if people want to keep that
as a light traffic list, maybe another list could be created). This way
we could all easily see what's applied, as a whole, and learn from it.
This is not so much for your own patches because you also post them to
patches and that is enough for me, but for Tom's and other people's
patches.
IIRC somebody offered to do this not long ago ...
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)
Neil Conway <neilc@samurai.com> writes:
The procedure I'm following is:
- for trivial / obviously correct patches, just apply them immediately
Check.
- for fairly simple patches, submit them to the list and apply them
fairly soon afterward (say, within 24 hours or 48 hours). When I
apply the patch, send another mail to wrap up the issue.
I think the pgsql-committers log message is sufficient indication that
you did it, and the followup message on -patches is unnecessary.
We usually acknowledge applying patches from non-committers, on the
theory that they might not be subscribed to pgsql-committers. But
for your situation I don't see the value in the extra message.
regards, tom lane
Neil Conway wrote:
P.S. BTW, how does everyone feel about the methodology I've been
using for submitting and applying patches? The procedure I'm
following is:- for trivial / obviously correct patches, just apply them
immediately- for fairly simple patches, submit them to the list and apply them
fairly soon afterward (say, within 24 hours or 48 hours). When I
apply the patch, send another mail to wrap up the issue.
I feel that you don't really need to "wrap up" the issue, because anyone
who cares enough will read the commit list.
- for more complex stuff, the usual submission & review process until
the patch is ready to be applied.If people don't want the additional mail when a patch is applied, I
can stop sending those to reduce the quantity of mail on -patches.
I'm also open to any other suggestions for procedural changes...
It's up to you. Normally it's OK to float a proposal and then install a
corresponding patch right away, but if you feel better when other
people look over the actual patch, feel free to post it.
Tom Lane wrote:
Neil Conway <neilc@samurai.com> writes:
The procedure I'm following is:
- for trivial / obviously correct patches, just apply them immediately
Check.
- for fairly simple patches, submit them to the list and apply them
fairly soon afterward (say, within 24 hours or 48 hours). When I
apply the patch, send another mail to wrap up the issue.I think the pgsql-committers log message is sufficient indication that
you did it, and the followup message on -patches is unnecessary.
We usually acknowledge applying patches from non-committers, on the
theory that they might not be subscribed to pgsql-committers. But
for your situation I don't see the value in the extra message.
Agreed. I just emailed Neil privately to say I think he is using good
judgement on when to apply and when to wait 24 hours.
--
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