Andres Freund writes:
> On 2014-04-04 17:24:00 -0400, Tom Lane wrote:
>> Maybe not many, but pg_dump itself certainly can try to do that.
>> (Most of the time, pg_dump won't dump things in pg_catalog, but there
>> are exceptions, eg --binary-upgrade dump of an extension containing
>> objects in pg
On 2014-04-04 17:24:00 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
> >> I don't find that to be a good idea at all. pg_dump is probably not the
> >> only code that believes it can select a creation target with search_path,
> >> no matter what t
Andres Freund writes:
> On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
>> I don't find that to be a good idea at all. pg_dump is probably not the
>> only code that believes it can select a creation target with search_path,
>> no matter what that target is.
> Sure, but how many of those are trying
On 2014-04-04 14:56:54 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I was actually suggesting that the only way to create something in
> > pg_catalog is to do it with a explicit schema qualified id. I realize
> > that that's not something backpatchable...
>
> I don't find that to be a good
Andres Freund writes:
> On 2014-04-04 14:32:46 -0400, Tom Lane wrote:
>> Hm. Seems pretty grotty, but it'd at least fix pg_dump's problem,
>> since pg_dump's lists are always "foo, pg_catalog" with no third
>> schema mentioned. I think what we'd actually need is to say
>> "pg_catalog cannot be s
On 2014-04-04 14:32:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I was thinking - but not saying explicitly - of rigging things so that
> > pg_catalog is ignored when searching for the target schema for object
> > creation unless explicitly specified. So if there's no other schema in
> >
Andres Freund writes:
> I was thinking - but not saying explicitly - of rigging things so that
> pg_catalog is ignored when searching for the target schema for object
> creation unless explicitly specified. So if there's no other schema in
> the search path you'd get the error about no "no schema
Josh Berkus writes:
> No, if we're fixing this, then we should have a separate
> "creation_target_schema" GUC. The fact that the only way to designate
> creation target schema was to put it at the start of the search path has
> *always* been a problem, since 7.3.
Well, if we were doing this in
On 2014-04-04 14:13:43 -0400, Tom Lane wrote:
> > How about simply refusing to create anything in pg_catalog unless it's
> > explicitly schema qualified? Looks a bit nasty to implement but doable?
>
> That's what happens already. The point is to do better. What we want
> for pg_dump's case is to
Andres Freund writes:
> On 2014-04-04 13:58:53 -0400, Tom Lane wrote:
>> Hm ... doesn't fix the problem for existing dump files, which are going to
>> say "search_path = foo, pg_catalog". However, we could modify it a bit,
>> so that the marker is put on schemas that can be skipped if missing for
On 2014-04-04 13:58:53 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I wonder if we could extend the search path syntax to specify whether a
> > schema should be used for creation of objects or not. Sounds somewhat
> > nasty, but I don't really have a better idea :(. Something like
> > search
On 04/04/2014 01:47 PM, Andres Freund wrote:
> I wonder if we could extend the search path syntax to specify whether a
> schema should be used for creation of objects or not. Sounds somewhat
> nasty, but I don't really have a better idea :(. Something like
> search_patch=public,!pg_catalog.
No, if
Andres Freund writes:
> On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
>> It strikes me that the real issue here is that the analogy to PATH is
>> fine for search_path's role as a *search* path, but it's not so good for
>> determining the creation target schema. I wonder if we should further
>> re
Hi,
On 2014-04-04 13:33:59 -0400, Tom Lane wrote:
> It strikes me that the real issue here is that the analogy to PATH is
> fine for search_path's role as a *search* path, but it's not so good for
> determining the creation target schema. I wonder if we should further
> redefine things so that th
14 matches
Mail list logo
