Re: Schemas causing problems :( - Mailing list pgadmin-support

From Dave Page
Subject Re: Schemas causing problems :(
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E41A7443@ratbert.vale-housing.co.uk
Whole thread Raw
In response to Schemas causing problems :(  (Vitaly Belman <vitalyb@gmail.com>)
List pgadmin-support

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
> Sent: 26 July 2004 14:41
> To: Vitaly Belman
> Cc: pgadmin-support@postgresql.org; Dave Page
> Subject: Re: [pgadmin-support] Schemas causing problems :(
>
>
> Dave, this problem originates from
> pgDatabase::GetSchemaPrefix removing the schema if it's on
> the search_path. AFAIR you arose the problem of search_path,
> but now I see that I changed it myself. It's obviously a
> mistake to suppress the schema when creating/modifying
> objects (unless public or pg_catalog), can you think of a
> situation *at all* that we might want to evaluate that in pgAdmin3?

I don't recall that discussion, but in general I think we should
completely ignore the search path. Consider a function: foo.dostuff().
The current code will return an empty schema prefix for a search_path of
public,bar,foo. What if there is also public.dostuff() or bar.dostuff()?
CREATE OR REPLACE could really screw up in that case...

Vitaly's problem is another good example of course.

I also don't like the notion of treating public as some kind of special
schema. From PostgreSQL's pov, its only special in that it's there by
default in template1 and the search_path. Other than that it's just
another schema and should be treated as such.

Regards, Dave.


pgadmin-support by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: Schemas causing problems :(
Next
From: Duane Winner
Date:
Subject: Re: pgadmin3 on freebsd