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

Hannu Krosing wrote:

> What we really need is a better PL interface, the current one has
> quite a few limitations. Corba may help here, but _not_ a simple
> Corba wrapper of existing api

    Actually  I'm  a  little  in doubt if calling it an interface
    isn't gone too  far.  The  only  difference  (from  the  call
    handlers  point  of  view) is that the fmgr calls one and the
    same  C  entry  point  for  different  functions  and  passes
    therefore  the  OID of the function meant. So in reality it's
    more another call technique than an interface.

    On the point on CORBA I say: If Someone can create a  general
    interface     that     makes    integration    of    external
    languages/applications as easy so little old  ladies  and  12
    year  old  pacman players can do it, than he should.  If that
    new, fantastic, glory technique is based on CORBA or COBOL, I
    wouln't mind - I would shout a welcome!

    I'm  not able to produce such a magic thing. All I can create
    are things like PL/Tcl, PL/pgSQL, the actual pain of the rule
    system  and  some other ugly ones. And as long as noone comes
    up with the above peace of magic, I'll go  on  providing  the
    things I can create.

    It  was hard to write them, so it should be hard to use them.
    I only try to make it not as hard as to learn an entirely new
    language  from  scratch. In the PL/Tcl tree there is a little
    test suite.  I'm sure that a Perl  expert  could  create  the
    same  suite  in  a  few minutes (like I did it) - but only in
    PL/Perl - never in PL/Tcl,  because  then  he  would  have  a
    larger learning curve ahead.

    Let  people  use  the  languages  they're  familiar with, and
    you'll get good, reliable, performat applications. Force them
    to use something they've never seen before and they'll "shoot
    theirself into the foot".

    To understand this one someone must (re)read:

        http://www.cs.rpi.edu/~edwardsb/shoot.in.foot.html

>
> > All completely non standard thing may (and should) be done outside of postgres
> > or in worst case by DYNALOAD mechanic.
>
> Currently we are doing it in your "worst case" way :)
>
> the v6.5 has even special scripts to create/destroy PLs. Only SQL and
> internal (compiled-in C) are "embedded" in non-removable way.
>
> Even PL/PGSQL must be installed to be used

    And  I  don't  think  that  having  PL/pgSQL  to  follow  the
    generalized  standard way all PL's must go is the worst case.
    IMHO it's the best of all cases. Think of other  standards  -
    ALL  Windows  applications  must use the Windows API - except
    for those created by M$. Maybe they have a good reason not to
    use the Windows API - they know it's internals.

> IMHO having better support for PLs should go further than just calling
> functions in SELECT or triggers - to make it possible for people to
> easily
> add new types/indexing schemes the PL should also be usable for
> input/output
> functions, access methods and maybe even for prototyping new fe/be
> protocol.

    For  PL/Tcl,  this  time  will  surely  come. When Tcl8.1 has
    settled so 8.0 could be considered the release that has to be
    supported  for  backward compatibility, I'll kick out the 7.6
    support  from  PL/Tcl.  This  would   again   increase   it's
    performance.

    The  actual  limitation  not  to  be able to create data type
    input/output functions is because the  call  handler  doesn't
    support  it.  Definitely,  it could! It already has to lookup
    pg_type to find the input/output functions  for  the  return-
    value/arguments.  If  the  OID in the pg_type tuples in-/out-
    function is the one the call handler actually is called  for,
    why not acting so?

    The PL/Tcl module you're seeing with v6.5 is mainly still the
    one I've developed based on Tcl7.6 (the fact that one and the
    same  sources  actually  compile  with 7.6 and 8.0 stands for
    itself). All the  above  features  would  have  required  the
    Tcl_Obj  interface  which  was  new to 8.0. But at the time I
    created it, 7.6 was the default in install packages of unices
    and surely there where many 7.5's still in use.  I decided it
    would be better to first support most Tcl  installations  and
    later force those who used it to do an upgrade.

>
> I hope to get a draft implementation of this in 6.5 before its official
> launch :)

    I'll be back...


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) #