/contrib 'cosmetic'

Karel Zak <zakkr@zf.jcu.cz> writes:

- (IMHO) is good evidently that all executable programs stored here use
prefix 'pg_', but with the exception:

vacuumlo
pgbench (instead pg_bench)
oid2name
ipc_check
fti[.pl]
findoidjoins

What rename it? After 7.1 output it will late, bacause users integrate
these stuffs to their programs/scripts.

Most of those were around in 7.0 or before, so it's already too late.
I'd agree with renaming ipc_check (that's just asking for name
conflicts). oid2name isn't very likely to hit a name conflict, but
maybe we should change it too.

regards, tom lane

Karel Zak writes:

- everything in the contrib tree has 'uninstall', with the
exception contrib/rserv

Feel free to implement it. ;-)

- every "WANTED_DIRS" has Makefile and is possible install it,
What contrib/start-scripts, contrib/tools and contrib/retep are?

retep is installed via build.xml when you install the jdbc driver.
start-scripts needs to be installed manually anway. 'tools' doesn't need
to be installed because they are source tools.

I mean user after 'make install' look at $(libdir)/contrib and not
walk in sources and search what is/isn't installed...

I don't think the contrib/Makefile is to be relied on except for cleaning.

In future ... please ignore patches those ignore the /contrib's practice
-- the trouble is overhaul the contrib tree during each version.

The reason it's in contrib is that it's a bit less than perfect. If we
were to prioritize on maintaining contrib, then we might as well fold it
into the core (which we ought to consider for some items). IMHO.

--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/

On Mon, Mar 19, 2001 at 05:50:01PM +0100, Peter Eisentraut wrote:

In future ... please ignore patches those ignore the /contrib's practice
-- the trouble is overhaul the contrib tree during each version.

The reason it's in contrib is that it's a bit less than perfect. If we
were to prioritize on maintaining contrib, then we might as well fold it
into the core (which we ought to consider for some items). IMHO.

Agree. You good remember previous state of the contrib -- something
wasn't compile-able, something was total dead ..etc. I want see nice code
in contrib and not say "the contrib is our trash and everybody can postpone
something here" (it not means currect state is bad. It's better than
before 7.1, it's care about future :-).

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Added to TODO:

* Rename some /contrib modules from pg* to pg_*

On Mon, Mar 19, 2001 at 05:50:01PM +0100, Peter Eisentraut wrote:

In future ... please ignore patches those ignore the /contrib's practice
-- the trouble is overhaul the contrib tree during each version.

The reason it's in contrib is that it's a bit less than perfect. If we
were to prioritize on maintaining contrib, then we might as well fold it
into the core (which we ought to consider for some items). IMHO.

Agree. You good remember previous state of the contrib -- something
wasn't compile-able, something was total dead ..etc. I want see nice code
in contrib and not say "the contrib is our trash and everybody can postpone
something here" (it not means currect state is bad. It's better than
before 7.1, it's care about future :-).

Karel

--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/

C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026