From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
---|---|
To: | "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de> |
Cc: | "Vitaly Belman" <vitalyb(at)gmail(dot)com>, <pgadmin-hackers(at)postgresql(dot)org> |
Subject: | Re: [pgadmin-support] Schemas causing problems :( |
Date: | 2004-07-26 14:52:30 |
Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E41A744A@ratbert.vale-housing.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgadmin-hackers |
> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
> Sent: 26 July 2004 17:28
> To: Dave Page
> Cc: Vitaly Belman; pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-support] Schemas causing problems :(
>
> 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.
Public only would work fine unless the user had an object in pg_catalog
(not advisable, but when did that stop some ppl)...
> >
> > 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.
Yeah - I thought you were implying treating public/pg_catalog
differently when you said "It's obviously a mistake to suppress the
schema when creating/modifying objects (unless public or pg_catalog)"
> The correct overall behaviour seems
>
> - find the first schema in search_path that exists.
> - If this is the schema in question, suppress it.
OK. Still might result in broken reverse engineered SQL when used in a
different session with a different search path of course.
> - (ignore all following schema names, this was the main problem)
Yup.
> - If schema = pg_catalog, suppress it.
Why? Any reverse engineered SQL will then incorrectly force objects into
the first existing schema in the search_path, not pg_catalog.
> Unfortunately, this search_path[i] = session_user is not
> absolutely stable (schema or user name may change), but it
> should be stable enough.
>
> Thoughts?
Fully qualify everything. I think it's the only truly infallible way.
Regards, Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2004-07-26 15:25:35 | Re: [pgadmin-support] Schemas causing problems :( |
Previous Message | cvs | 2004-07-26 13:35:36 | CVS Commit by andreas: fix search_path/schema prefix bug |