On Thu, Jul 13, 2006 at 07:17:31PM -0400, Tom Lane wrote:
> There has been talk of attaching a search_path setting to each function
> so that it's independent of the caller's search_path, but the
> performance hit seems a bit daunting. In any case it's not pg_dump's
> fault that this feature doesn
On Thu, Jul 13, 2006 at 07:17:31PM -0400, Tom Lane wrote:
> Phil Frost <[EMAIL PROTECTED]> writes:
> > I've recently migrated one of my databases to using veil. This involved
> > creating a 'private' schema and moving all tables to it.
> > ...
> > In doing so, I found to my extreme displeasure that
On 7/14/06, Tom Lane <[EMAIL PROTECTED]> wrote:
[ problems with missing schema in dump ]
No, not one of these things can be blamed on pg_dump.
Ok, its not exactly bug but still a big annoyance that
instead dumping fully qualified names it juggles with
search path. And I'm annoyed as a user l
Phil Frost <[EMAIL PROTECTED]> writes:
> I've recently migrated one of my databases to using veil. This involved
> creating a 'private' schema and moving all tables to it.
> ...
> In doing so, I found to my extreme displeasure that although the
> database continues to function flawlessly, I can no
ISTM that pg_dump needs to produce output that includes schema names,
though I'm not sure what side-effects that would have. I know one
issue is that it'd make it next to impossible to move things to a
different schema just be editing the dump.
On Jul 5, 2006, at 9:47 AM, Phil Frost wrote:
I've recently migrated one of my databases to using veil. This involved
creating a 'private' schema and moving all tables to it. Functions
remain in public, and secured views are created there which can be
accessed by normal users.
In doing so, I found to my extreme displeasure that although the
d
