Re: [pgadmin-support] Schemas causing problems :(
От | Andreas Pflug |
---|---|
Тема | Re: [pgadmin-support] Schemas causing problems :( |
Дата | |
Msg-id | 41053105.4080109@pse-consulting.de обсуждение исходный текст |
Список | 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 по дате отправления: