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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers