From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Vitaly Belman <vitalyb(at)gmail(dot)com> |
Cc: | pgadmin-support(at)postgresql(dot)org, Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
Subject: | Re: Schemas causing problems :( |
Date: | 2004-07-26 13:41:27 |
Message-ID: | 41050A07.3020803@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-support |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2004-07-26 16:27:49 | Re: [pgadmin-support] Schemas causing problems :( |
Previous Message | Andreas Pflug | 2004-07-26 13:15:53 | Re: compile problem |