Обсуждение: Schemas causing problems :(

I have the following problem, when I am editing a function in PGAdmin
that is not in a public schema yet that it is in the search_path and
doing apply it does the following:

CREATE OR REPLACE FUNCTION blabla();

Meaning it omits the schema name and so even though the function I
edited was not in public schema, it ends there anyway, as it is higher
in the search_path. Why doesn't PGAdmin add the schema name before the
function? It sounds rather trivial to me =\.

Thanks.

-- ICQ: 1912453AIM: VitalyB1984MSN: tmdagent@hotmail.comYahoo!: VitalyBe

Vitaly Belman wrote:
> I have the following problem, when I am editing a function in PGAdmin
> that is not in a public schema yet that it is in the search_path and
> doing apply it does the following:
> 
> CREATE OR REPLACE FUNCTION blabla();
> 
> Meaning it omits the schema name and so even though the function I
> edited was not in public schema, it ends there anyway, as it is higher
> in the search_path. Why doesn't PGAdmin add the schema name before the
> function? It sounds rather trivial to me =\.

Fine, you're welcome supporting us!

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?

In the meantime, the search_path option can be set to public to get 
correct behaviour.


Regards,
Andreas

> -----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.