Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux