Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> This assumes that the search path at creation time has something to do
>> with the path you'd like to use at execution, which is unlikely to be
>> the case in existing pg_dump output, to name one example. I don't
>> really want to get into doing the above.
> pg_dump will have to do a ALTER FUNCTION SET command anyways, no?
You're missing the point: this change will break existing pg_dump
output, because pg_dump feels free to set the search_path for its own
purposes. The same is true of other GUC variables that might be
automatically absorbed into CREATE FUNCTION: there is not any very good
reason to suppose that their values when the dump is restored are really
what should be used. The argument is slightly more credible with
respect to interactively-issued commands, but for pg_dump it's simply
wrong.
What we might change pg_dump to do in future is a separate topic,
but we can't make that kind of change in the semantics of existing
dumps.
regards, tom lane
