Re: Final /contrib cleanup -- yes/no? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Final /contrib cleanup -- yes/no?
Date
Msg-id 16137.1226010249@sss.pgh.pa.us
Whole thread Raw
In response to Re: Final /contrib cleanup -- yes/no?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Final /contrib cleanup -- yes/no?  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> The way the SQL scripts currently work, there is no way to manage what 
> schema the contrib modules get built in *except* to edit the scripts. 

Right, that's the intended and documented way to do it.

> In fact, because of the SET statements, a DBA who might *reasonably* 
> expect that setting PGOPTIONS would allow him to determine that will be 
> unpleasantly surprised when the module ends up in "public" anyway.

I don't see that this is a reasonable expectation; it has never worked
in any previous release, and the documentation explicitly says to do the
other.  Also, at least some of the proposed forms of a module facility
would have the effect of overriding any such approach anyhow.

Again, I'm not for whacking around the procedures for dealing with
contrib each time we make a release.  We should change it once when we
have a shot at getting it right.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Final /contrib cleanup -- yes/no?
Next
From: "Joshua Tolley"
Date:
Subject: Re: Proposed Patch to Improve Performance of Multi-Batch Hash Join for Skewed Data Sets