Re: [pgadmin-support] Schemas causing problems :( - Mailing list pgadmin-hackers

From Andreas Pflug
Subject Re: [pgadmin-support] Schemas causing problems :(
Date
Msg-id 41053105.4080109@pse-consulting.de
Whole thread Raw
List pgadmin-hackers
This is really hackers stuff.


Dave Page wrote:
>
>
> 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...

Some logic black holes... preliminarily public only.

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

A grep showed that only FK has handles public special, all other places
go through pgDatabase::GetSchemaPrefix.

The correct overall behaviour seems

- find the first schema in search_path that exists.
- If this is the schema in question, suppress it.
- (ignore all following schema names, this was the main problem)
- If schema = pg_catalog, suppress it.

Unfortunately, this search_path[i] = session_user is not absolutely
stable (schema or user name may change), but it should be stable enough.

Thoughts?

Regards,
Andreas


pgadmin-hackers by date:

Previous
From: cvs@cvs.pgadmin.org
Date:
Subject: CVS Commit by andreas: fix search_path/schema prefix bug
Next
From: "Dave Page"
Date:
Subject: Re: [pgadmin-support] Schemas causing problems :(