Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> With all the recent discussion on contrib modules etc.. I would like to
>> offer the following suggestion.
> AFAICT you're proposing an entirely cosmetic reclassification of /contrib.

For the most part yes. Perception is reality and all. The exception
being that modules are installed by default.

> Aside from the difficulty of getting agreement on which ones should be
> "in" and which "out", what does that really buy us?

True and I am sure that people with more time to waste than I would like
to spend days creating a thread that is 500 responses long on why their
particular module should be a module or a contrib.

>  The thing that
> would be really useful to work on is developing a concrete
> representation of a "module" that pg_dump would understand, so that you
> could e.g. tell it to omit btree_gist from a dump.

I am offering what I can.

>  It might be that
> just segregating a contrib module into its own schema would be
> sufficient, or maybe that wouldn't work well because of making people
> need to deal with long search paths.

I do like the contrib schema idea would could easily be melded into this
proposal. I don't like the idea that all of contrib would automatically
be included which is one of the reasons I wanted to split this up.


Joshua D. Drake

>                       regards, tom lane


      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997

Donate to the PostgreSQL Project:
PostgreSQL Replication:

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to