Re: [pgadmin-support] Schemas causing problems

Dave Page wrote:
>  
>
> > -----Original Message-----
> > From: Andreas Pflug [mailto:pgadmin@xxxxxxxxxxxxxxxxx] 
> > Sent: 26 July 2004 17:28
> > To: Dave Page
> > Cc: Vitaly Belman; pgadmin-hackers@xxxxxxxxxxxxxx
> > 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.
pg_catalog is read-only (well, usually...), and displays only 
optionally. When context menu is reworked, we should disable 
creation/modification too.
> > 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. 
You'd wipe your eyes if we really did. How do you like pg_catalog.int4, 
pg_catalog.text and so forth? <shrug>
> I think it's the only truly infallible way.

And the ugliest.
Maybe we should invent a switch if default schema suppression is not 
wanted; the search path option seems useless.
Regards,
Andreas

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
     subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
     message can get through to the mailing list cleanly