(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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
