At 06:58 AM 5/14/02 +0100, Oliver Elphick wrote:
> > retarget a dump script to be reloaded in some other schema. If the
> > dump is cluttered with umpteen thousand copies of the schema name
> > that's going to be difficult.
>
>sed -e 's/ old_schema\./ new_schema./g'
>
>I don't think you should al
On Tue, 2002-05-14 at 07:08, Tom Lane wrote:
> You have no fear that that "sed" will substitute some places it
> shouldn't have? Also, what makes you think this'll be a "rarely
> used" feature? I'd guess that people load dumps every day into
> databases that have different names than the ones th
Oliver Elphick <[EMAIL PROTECTED]> writes:
>> Perhaps instead of "readability" I should have said "editability".
>> The thought that is lurking behind this is that you might want to
>> retarget a dump script to be reloaded in some other schema. If the
>> dump is cluttered with umpteen thousand co
On Tue, 2002-05-14 at 01:42, Tom Lane wrote:
> [EMAIL PROTECTED] (Neil Conway) writes:
> > I'd prefer this method -- IMHO the readibility of dump scripts isn't
> > a top priority (or if it is, we're not doing very well in that regard
> > any). I think dump scripts should be as verbose as is necess
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> How did you intend on dealing with the case where a user removes
> public or otherwise changes the permissions / ownership on it?
I have that as one of my "to think about" items. The best idea I have
at the moment is to assume it exists, but include GRA
> Doesn't seem very workable for the public schema. I suspect pg_dump
> has to special-case public anyway, to some extent, but this doesn't
> really get us around the DROP problem for individual objects AFAICS.
Most people in the know will probably never use public due to
portability issues betw
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> ... Based on the assumption a DROP SCHEMA statement will also
> be issued.
Doesn't seem very workable for the public schema. I suspect pg_dump
has to special-case public anyway, to some extent, but this doesn't
really get us around the DROP problem for
> No, it's a necessary thing to comply with the SQL standard.
> The standard thinks all the predefined names are keywords and
> should override user names. Therefore there *must* be a mode
Hmm.. I'm not fond of this part of the standard in this case -- though
it's got to be there for good reaso
[EMAIL PROTECTED] (Neil Conway) writes:
> I'd prefer this method -- IMHO the readibility of dump scripts isn't
> a top priority (or if it is, we're not doing very well in that regard
> any). I think dump scripts should be as verbose as is necessary to
> ensure that they can't be misinterpreted.
P
"Rod Taylor" <[EMAIL PROTECTED]> writes:
> Afterall, if you create a my_schema.pg_class table (for whatever
> reason), and used my search path as my_schema, I'd expect my own to be
> hit with my queries.
If you want that behavior, you can set the search path as
"my_schema, pg_catalog". This does
On Mon, May 13, 2002 at 02:58:08PM -0400, Tom Lane wrote:
> 1. Explicitly qualify target-object names in the DROP commands,
> 2. Modify the backend so that DROP has a different behavior from
> other commands
> Choice #1 is logically cleaner but would clutter the dump script with
> many more expl
> set search_path = my_schema;
> This works fine unless the object name duplicates a system object;
> in that case, since the effective search path is really "pg_catalog,
> my_schema", the DROP will find and try to drop the system object.
I must have missed that day. Why is that exactly? Clien
I'm working on cleaning up loose ends in pg_dump, and in particular
trying to ensure that objects in user schemas can be named the same
as system objects without conflicts. Most of this works now, thanks
to Peter's idea about explicitly setting the search path to include
just the current target s
13 matches
Mail list logo
