Thread: default namespace (schema) confusion
I have been looking forward to schemas (namespaces) for sometime.
I had not been able to decipher the schema symantics necessary for a
default schema, until I hacked the source a bit.
Now I know that the rules to get a default schema usingdb_user_namespace = truesearch_path = '$user,public'
in postgresql.conf
the user logs in aspsql testdb testuser
but the userid is reallytestuser@testdb
if a schema named "testuser@testdb" exists
the user gets it as a default schema
otherwise the default schema is public;
and if the user is a global user
the login ispsql testdb globuser@
and the required schema is "globuser"
this use of "@" in the default schema is a bit counter intuitive
so I offer the following patch against CVS
it tries the userid as found in pg_user,
then strips off the @db stuff if possible
--- src/backend/catalog/namespace.c Thu Oct 17 21:23:34 2002
+++ src/backend/catalog/namespace_2.c Thu Oct 17 21:21:52 2002
@@ -1386,8 +1386,10 @@ if (HeapTupleIsValid(tuple)) { char *uname;
+ char *uname_local; uname = NameStr(((Form_pg_shadow)
GETSTRUCT(tuple))->usename); namespaceId =
GetSysCacheOid(NAMESPACENAME,
CStringGetDatum(uname),
0, 0, 0);
@@ -1396,7 +1398,25 @@ !intMember(namespaceId,
oidlist) &&
pg_namespace_aclcheck(namespaceId, userId,
ACL_USAGE) == ACLCHECK_OK)
+ { oidlist = lappendi(oidlist,
namespaceId);
+ }
+ else
+ {
+ uname_local = (char *)
malloc(strlen(uname)); + strcpy
(uname_local,uname);
+ uname_local =
strtok(uname_local,"@");
+ namespaceId =
GetSysCacheOid(NAMESPACENAME,
+
CStringGetDatum(uname_local),
+
0, 0, 0);
+ if (OidIsValid(namespaceId) &&
+ !intMember(namespaceId,
oidlist) &&
+
pg_namespace_aclcheck(namespaceId, userId,
+
ACL_USAGE) == ACLCHECK_OK)
+ oidlist =
lappendi(oidlist, namespaceId);
+ free(uname_local);
+ }
+ } } else
Carl Anderson <candrsn@mindspring.com> writes:
> this use of "@" in the default schema is a bit counter intuitive
> so I offer the following patch against CVS
Hmm, this seems like a wart, but then the db_user_namespace feature
is an acknowledged wart already.
I think I'd be willing to hold still for this if it happens only when
db_user_namespace is on. Comments anyone?
> + uname_local = (char *)
> malloc(strlen(uname)); + strcpy
> (uname_local,uname);
Use pstrdup, please.
regards, tom lane
Tom Lane wrote: > Carl Anderson <candrsn@mindspring.com> writes: > > this use of "@" in the default schema is a bit counter intuitive > > so I offer the following patch against CVS > > Hmm, this seems like a wart, but then the db_user_namespace feature > is an acknowledged wart already. > > I think I'd be willing to hold still for this if it happens only when > db_user_namespace is on. Comments anyone? I dislike double-testing the username in schema areas but not other places. Seems if we do it, we should do it consistently for all username references, or not at all. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> I dislike double-testing the username in schema areas but not other
> places. Seems if we do it, we should do it consistently for all
> username references, or not at all.
What other places do we have an explicit dependence on the username?
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I dislike double-testing the username in schema areas but not other > > places. Seems if we do it, we should do it consistently for all > > username references, or not at all. > > What other places do we have an explicit dependence on the username? Uh, what about CREATE/ALTER/DROP USER, and pg_hba.conf. Of course, those are more admin, but isn't the schema also sort of admin too? I am also concerned about opening cases where a CURRENT_USER test doesn't match the user's schema. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073