Christopher Browne wrote: > Vis-a-vis the attempt to do nested naming, that is "ns1.ns2.table1", > there's a pretty good reason NOT to support that, namely that this > breaks relational handling of tables. PostgreSQL is a *relational* > database system, hence it's preferable for structures to be > relational, as opposed to hierarchical, which is what any of the > suggested nestings are.
Organizing the tables into a multi-level namespace, either fixed-depth or variable-depth, rather than using a flat namespace, does not make the database any less relational, because the above definition and any others still hold. The "less relational" argument above is a red herring or distraction. One can argue against namespace nesting just fine without saying that. -- Darren Duncan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree with Darren. One thought that came to my mind was to use a different separator between two namespaces and/or between the database identifier and the rest of the "path". Examples: ns1!ns2.table OR database@ns1.table OR database@ns1!ns2.table I've been following only some of the discussion but it seems that much ambiguity would be lost by using different separators. Schemas themselves are already non-standard so it isn't like we are constrained here in what is chosen. Just some quick thoughts I've had but haven't fully considered how they would fit in to the existing setup. But is there is any major reason why choosing different separators would not work? Also, within search_path, some form of wild-card selector would be desirable: ns1!*. I'm not opposed to having to be explicit about the search_path in order to avoid name collisions; though it would be nice if VIEWS had some kind of "SET" syntax, like functions do, so that the definer can specify the search_path that the view will resolve against. David J. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
