Re: [HACKERS] Creating temp tables inside read only transactions

On Jul11, 2011, at 07:08 , Darren Duncan wrote:
> 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.
>
> A relational database is a database in which all data is kept in
> relation-typed variables, which SQL calls tables, and you can perform
> all queries and updates with just relation-valued expressions and
> statements.
>
> 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 point was not, I think, that tables aren't suddenly relations once
namespaces are nested, but that the data model of the dbms *itself*,
i.e. the data model that defines the relationship between namespaces,
types, columns, type, ... becomes harder to map to the relational model.

For example, if namespaces can be nested, you'll need to resort to
recursive SQL and/or arrays far more often if you inspect the structure
of a database.

Btw, another argument against nested namespaces is that it actually
doesn't buy you anything in SQL, even if you solve the parsing
ambiguities. In programming languages, namespaces not only prevent
name clashes, the also defines the possible scopes to resolve unqualified
names with. For example, if you do
void f() { printf("outer"); }

namespace a {
void f() { printf("inner"); }

namespace b {
void g() {f();}
}
}
in C++, then a::b::g() prints "inner". But in PostgreSQL, the scope in
which to resolve unqualified function is entirely determined by the the
search_path setting, *not* by the scope of the object containing the
unqualified name. Nested namespaces thus simply become of matter of
syntax - i.e., whether you can write a.b.c, or need to write "a.b".c.

best regards,
Florian Pflug