Re: [HACKERS] is GiST still alive? - Mailing list pgsql-chat

From Kurt at DBC
Subject Re: [HACKERS] is GiST still alive?
Date
Msg-id 3F974CF4.90509@dbc.co.nz
Whole thread Raw
List pgsql-chat
Christopher Browne wrote:

> No, "tables" wouldn't be the right way to do it.
>
> But it's going to be troubled, in any case, because of the
> every-popular mixtures of:
>  a) Often weird declarations of what character sets are in use;
>  b) Pointers to other parts of a document;
>  c) What's a "database" going to consist of?  One XML document?  Or
>     many?  And if many, then then how do you have a centralized
>     reference point to navigate from to find the document that you
>     want?
> And "navigate" was a carefully chosen word; what you then have is
> essentially a network database system, and have to then start making
> up ways of describing queries.  XQuery may be better than CODASYL of
> yesteryear, but you're still left writing a lot of recursive code.
> (Thus making those that understand the Lambda Nature more powerful...)
>
> At the end, do you have a "database?"  Or just a set of documents?
> It's hard to tell, a priori.
>
[Trimmed comments on utility of such features]

transferred from pgsql-hackers to pgsql-chat.

Coincidentally, just recently looked at Fongs "The design
and implementation of the POSTGRES query optimizer2"  (referenced in the
Developers Guide) which implies that one of the initial goals of
postquel and postgres was to handle similar structures :

"The basic problem here is that the relational model is not well-suited
for representing hierarchical relationships. As a solution, Stonebraker
has proposed embedding queries within data fields and using these
queries to express the hierarchical relationship between the
corresponding tuple and information elsewhere in the database [STON84].
Using this idea, which POSTGRES supports, our complex object example is
now represented as shown in figure 2.5. To retrieve information executed
by the queries embedded within this data field, the user would issue the
following query:

execute (COBJECT.components) where COBJECT.coid = 1.

Thus, n join queries reduce to a single execute query. In addition,
users can selectively retrieve information
linked through these hierarchies by nesting attributes"

Go's around, comes around.
Cheers, Kurt.


pgsql-chat by date:

Previous
From: "aladino"
Date:
Subject: Testing
Next
From: xier@in.tum.de
Date:
Subject: PostgreSQL delete the blank in the end of the String automatically. how can I avoid it?