Re: Per-function search_path => per-function GUC settings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per-function search_path => per-function GUC settings
Date: 2007-09-01 19:12:44
Message-ID: 24544.1188673964@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Tolley 2007-09-01 19:17:11 Re: Per-function search_path => per-function GUC settings
Previous Message Tom Lane 2007-09-01 19:03:14 Re: Per-function search_path => per-function GUC settings