Re: Final /contrib cleanup -- yes/no?

Tom,

> I don't recall that having been proposed, and I don't think it's really
> a good idea.  We intentionally put those SETs in, not that long ago.

I haven't been able to find any reasoning on any list why those SETs 
where a good idea.  Bruce put them in, but apparently without 
discussion.  Unless you have a link for something I can't find in search?

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. 
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.

For that matter, I really don't see the point of explicitly setting the 
default schema ("public") in the scripts.  Why bother?

> The effects of that haven't been debated, either.  Are you sure none of
> those scripts rely on surviving errors?  What about the possibility of
> other scripts including them when already inside a BEGIN block?

Hmmm, I can see that.  Not that important given that we have the remove 
scripts.  I need to finish testing whether the remove scripts actually 
remove everything, though.

> The thing we really need to make that stuff nice is a proper module
> facility.  Changing stuff at the margins in the meantime doesn't really
> do much except create more different possible behaviors that people will
> have to deal with.

Yeah, but we're clearly not getting that done for 8.4, so I'm trying to 
do a little admin cleanup to live with for the next year.  This isn't 
based on idle conjecture; this came up again because I'm writing scripts 
to automatically build PostgreSQL servers, and the SET search_path thing 
keeps biting me on the tuchas.

--Josh