Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)

From: Nick Rudnick <joerg(dot)rudnick(at)t-online(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Date: 2011-02-08 07:23:15
Message-ID: 4D50EF63.7070406@t-online.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(my last two posts seemingly did not reach the HACKERS forum, so please
let me resend the last one ;-) )

May I sum up?

o in the recent there are no efforts known to experiment with
reference types, methods, or rule inference on top of PostgreSQL --
advice that can be given mostly points to the given documented
functionality

o inside the PostgreSQL community, there is not many knowledge in
circulation in regard of performance effects of using deeply nested data
structures (with the possible exception of XML handling) or doing rule
inference on top oof PostgreSQL -- but at least, there also are no
substantial contraindications

o extensions of PostgreSQL to support such a kind of usage have to be
expected to be expected to be rejected from integration to the code base
core -- i.e., if they are done, students have to be told «you can't
expect this to become a part of PostgreSQL»

Is this understood correctly, especially the last point, or did
Robert/Tom just specifically address syntactical conflicts (between
schema and object semantics) with the point notation?

If not, it might be discouraging for lecture, as there might be interest
to present something which at least might be imagined once to become a
standard tool.

Otherwise, the striking lack of academical initiatives in the area of OO
and rule inference on top of PostgreSQL appears to me as a demand to

a. check out academic sources, whether principle efficience issues of
backend design discourage it so obviously that people do not even try it
out

b. if this is not the case, to propose this professor to try to fill the
gap... ;-) In this case, regarding method semantics extensions, avoiding
conflicts with existent language constructs certainly will be
preferable, as these will be small projects.

Cheers, Nick

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-02-08 07:57:42 Allow pg_archivecleanup to ignore extensions
Previous Message Heikki Linnakangas 2011-02-08 07:07:46 Re: [COMMITTERS] pgsql: Implement genuine serializable isolation level.