-----Original Message-----
From: Andreas Pflug [mailto:[EMAIL PROTECTED] Sent: 26 July 2004 17:28
To: Dave Page
Cc: Vitaly Belman; [EMAIL PROTECTED]
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 [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
