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
finewithout 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
identifierand 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
thereis 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
explicitabout 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.