Re: pg_dump.options.diff

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca>
Cc: "Manfred Koizar" <mkoi-pg(at)aon(dot)at>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "PostgreSQL Patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: pg_dump.options.diff
Date: 2003-01-02 23:16:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

"Serguei Mokhov" <mokhov(at)cs(dot)concordia(dot)ca> writes:
>> But there's no good place to put it. I'd say just stick it into each
>> tool; it's no worse than repeating the existence of a "usage()"
>> subroutine in each tool.

> It ended up being in dumputils.h

I really don't like putting a macro with a name as short as "xo" into a
header file, even one of relatively narrow scope. It's too likely to
create weird conflicts. My inclination is to make the coding be more

static void
#if defined(HAVE_GETOPT_LONG)
#define xo(longOption,shortOption,desc) printf("%s %s\n", longOption, desc)
#define xo(longOption,shortOption,desc) printf("%s %s\n", shortOption, desc)

... lots of xo() calls ...

#undef xo

This gives us the convenience of a very short name within the usage()
subroutines, while not polluting the namespace for everyplace else in
these utilities.

As I said before, duplicating the definition of xo() in each file that
uses it doesn't bother me a bit; it's too simple for that to be a
significant objection.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lamar Owen 2003-01-02 23:18:23 Upgrading rant.
Previous Message Peter Eisentraut 2003-01-02 23:07:52 Re: PostgreSQL Password Cracker

Browse pgsql-patches by date

  From Date Subject
Next Message Rod Taylor 2003-01-02 23:27:10 Re: ALTER TABLE .. SET WITH / WITHOUT OIDS
Previous Message Tom Lane 2003-01-02 23:08:38 Re: ALTER TABLE .. SET WITH / WITHOUT OIDS