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.
Sincerely,
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
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
---------------------------(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
match
