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

Oleg Broytmann <phd@emerald.netskate.ru> writes:
>   I know exactly 1 (one) program that incorporate (embed) Perl interpreter
>- - it is editor VIM (well-known vi-clone from www.vim.org). I think anyone
>who want to learn how to embed perl may start looking int vim sources.

Also now GIMP.

>   Yes, I am biased toward Python, but I cannot say "I recommend embed
>Python to construct PL/Python" - I have no time to lead the development,
>and I doubt there are many pythoners here (D'Arcy?).

I went down that road a little ways to see what it looked like, and decided
that was the wrong road to take.

The reason people want an embedded procedural language is because procedures
in such a language have access to the guts of the backend, and can perform
many operations much more efficiently than having to go push everything
through the FE->SQL->compiler->executor->tuple list->FE->lather->rinse->repeat
bottleneck. 

I decided that the proper solution was to expose all the internal guts of
the backend through a proper CORBA interface.  That way, any language with
an ORB could act as an embedded procedural language.

Currently, I'm working on imbedding ORBit into Python to get my skills up
to speed.  When that's accomplished, I intend to tackle PostgreSQL.  For
a proof of concept, you can look at mod_corba (ORBit embedded in Apache,
exposing the Apache API).
-Michael Robinson

Michael Robinson wrote:

> The reason people want an embedded procedural language is because procedures
> in such a language have access to the guts of the backend, and can perform
> many operations much more efficiently than having to go push everything
> through the FE->SQL->compiler->executor->tuple list->FE->lather->rinse->repeat
> bottleneck.

    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.

>
> I decided that the proper solution was to expose all the internal guts of
> the backend through a proper CORBA interface.  That way, any language with
> an ORB could act as an embedded procedural language.

    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!


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#========================================= wieck@debis.com (Jan Wieck) #

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