Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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 

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 

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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group