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