Re: [HACKERS] PL/Lang (was: Priorities for 6.6)

wieck@debis.com (Jan Wieck) writes:
>    That's  one reason. Another one is that you can create stored
>    procedures     that     get     triggered      on      events
>    (INSERT/UPDATE/DELETE)  and can perform referential integrity
>    checks and other things then.
>
>    Some of them  could  also  be  done  by  constraints  (if  we
>    sometimes  have  the  rule  system  powerful enought to do it
>    correctly). Some can't.

Yes, this is true.  However, between SQL, and PL/PGSQL, I think we have
this covered, and I don't see a lot of urgency for adding new languages
just for this purpose.

>    And how does your CORBA get triggered  in  the  case  someone
>    uses  the  good  old psql? Or MUST everything then talk CORBA
>    and you disable any other kind  of  access  completely?  Note
>    that  for  a trigger that has to ensure referential integrity
>    it's not enough to say "it will be triggered if the user uses
>    the  correct  access  path".  It  has to ensure that the user
>    doesn't use the wrong one!

Well, that's the nice thing about ORBit.  You can link two CORBA-connected
systems into one binary, and ORBit will give a clean and efficient in-process
connection between the two.  So, just as pgsql can expose it's guts via
CORBA, so, too, can the programming runtime of your choice.  All that's
required (in theory) is a one-time wrapper for pgsql's current embedded-
language API, and you don't have to mess with the pgsql side ever again.  Of
course, this win only applies to languages with ORBit bindings (currently C,
with C++, Python, Ada, and several others in the pipeline).

But, again, I don't see a lot of urgency for this kind of solution.
-Michael Robinson