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

Hi Josh,

at first, thanks for all the interesting info given
> Correct, AFAIK.
>> 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»
> Not necessarily.  We "rule out" *very* few things from PostgreSQL; I
> think the TODO list only has 3 ideas which are contraindicated.
After reading these points, I would say it really is a very liberal 
policy... and I can't resist the temptation to ask about garbage collection:

I remember well PostgreSQL has an own garbage collection (palloc() 
etc.;I only know it is in utils of the backend, at mmgr), but I didn't 
find it on the TODO list; so

o   would you say "hands off the garbage collection" or could you 
imagine extensions?

o   would you consider the PostgreSQL garbage collection to be rather 
specific (e.g., DBMS specific optimizations) or heavily interwoven into 
the code -- or could it be conceivable that behaviour requirements from 
PostgreSQL could be specified so far that alternative garbage 
collections can be developed and inserted?
> However, the warning is that this particular *set* of ideas has some
> very high hurdles to jump before it could be considered seriously for
> core, and that none of the existing committers seem interested in
> helping with it.  So the level of difficulty for the implementer would
> be considerably greater than for many other patches of less invasiveness
> and clearer apparent utility.
>
> Among the hurdles are:
> a. performance: you'd have to work out how to make nested object
> resolution not take forever and burn up the CPUs
Time for a 'coming out': In the last years, I have mostly worked with 
pure typed declarative languages (Haskell, Mercury), so I personally 
have a type system like Hindley-Milner in mind, which by concept does 
not have infinite pointer chains and also in other regards seems to be 
in much closer relationship with relational database systems (an 
interesting, though early state effort: http://groups.inf.ed.ac.uk/links/).

As (partially due to emerging multicore technology) the trend seems to 
go into this direction (Scala for Java, inclusion of FP functionality in 
C++), and such type system may be regarded as competitive with OO, I 
personally don't see much motivation for a such forced marriage like 
ISO/IEC 9075-10 (SQL/OLB).

The difficulty in regard of pure typed declarative languages rather 
seems to be garbage collection (therefore the question above), as it in 
these language environments uses to be a very sophisticated piece of 
programming, subject of intensive research efforts, so it would be a 
problem if the PostgreSQL garbage collection would be equally complex.
> b. resolution: you'd need to come up with an object naming practice
> which compliments, intead of conflicts with, the SQL-standard syntax
of course...
> c. utility: you'd have to demonstrate why all this was actually useful.
>
in short gross words: a typed rulebase extension. ai. joint-venturing 
with leading teams in this area.
>> 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?
> Syntactic conflicts are also significant, as anyone who's used EDB's
> "packages" mod can tell you.  So these would need to be worked out as
> well, and NOT in a way which breaks backwards compatibility.
completely d'accord...
>> 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
> Hmmm.  I don't know about that; I've never seen that academics *cared*
> whether or not their code god into -core.
>
Unfortunately this is well said...

Thanks for your infos,
    Nick