Обсуждение: /contrib 'cosmetic'

Hi,after long time I see the /contrib tree and I have I small notes.
- (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. -
everythingin the contrib tree has 'uninstall', with the   exception contrib/rserv
 
- every "WANTED_DIRS" has Makefile and is possible install it,   What contrib/start-scripts, contrib/tools and
contrib/retepare?
 
  I mean user after 'make install' look at $(libdir)/contrib and not  walk in sources and search what is/isn't
installed...
In future ... please ignore patches those ignore the /contrib's practice 
-- the trouble is overhaul the contrib tree during each version.

ThanksKarel

-- Karel Zak  <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz,
http://mape.jcu.cz

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

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

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/

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,
Pennsylvania19026