Robert Haas <robertmhaas@gmail.com> writes:
> If for some reason we needed to have tables that happened to be called
> x.y.z and a.b.c accessible from a single SQL session, we could allow
> that much more simply by allowing schemas to be nested. Then we could
> allow arbitrary numbers of levels, not just three.
FWIW, I actually tried to do that back when we first introduced schema
support (the fact that the code calls them namespaces and not schemas
is a leftover from that idea). It turns out to be a whole lot harder
than it sounds, because of the ambiguity you get about which name goes
at what level. A simple example of this is: if you write "x.y" in a
query, is that meant to be table x's column y, or is it meant to be
field y within a composite column x of some table in the query?
We've resolved that by requiring you to write "(x).y" when you mean
the latter, but it's not exactly an intuitive or pleasant answer.
In the same way, if namespaces can be nested to different levels,
it gets really messy to support abbreviations of any sort --- but
the SQL spec requires us to be able to do so.
regards, tom lane