Re: [HACKERS] rule system, perl and other good stuff

Hi,

>
>
> don't want to bring up a touchy subject, BUT... does the rule system
> actually work, and if not, what are our plans?  It would extend the
> functionality of postgresql quite a bit and make it much more
> attractive..  also I'm working on a modified version of pg with perl
> language support.  that's right, perl.  so far I've got it to the
> point where you can create perl functions (using anon sub refs) and
> access your arguments and perform operations (from pg_operator) on
> them.  I'll get the patches together soon, once I add operator
> overloading :)

    The  rule  system is wired up in some places. Especially it's
    impossible to have the values of the OLD and  NEW  tuples  in
    UPDATE rules. But we have triggers that can do all the things
    rules might do.

    The function and trigger manager  in  6.3  are  prepared  for
    things  like functions in perl. There is a new command CREATE
    PROCEDURAL LANGUAGE.  Look at the create_language manpage for
    details.    Except   for  user  defined  type  input-/output-
    functions anything can  be  done  in  a  procedural  language
    (functions,  triggers,  operators,  aggregates).  It would be
    very nice if your perl support makes use of the  API  defined
    for procedural languages.

    I've already written a call handler for the Tcl language that
    supports functions and  trigger  procedures  written  in  Tcl
    (it's  not  in  the  contrib up to now, mail me if you want a
    developers copy). The  procedural  language  support  of  the
    backend  is  a  result  from  that work. As long as your perl
    stuff isn't able to handle things that cannot be  done  in  C
    right  now (like returning sets), there is absolutely no need
    to patch the backend again.

    And I currently work on a pure PL/pgSQL  handler  independent
    of  other  things  like  perl/Tcl.  This  one  will  also  be
    implemented as a handler for the procedural language support.

>
> one more thing -- what about making the listen/notify interface
> synchronous?  what must be done?  and... and...  select foo[5:] for
> elements 5 and onward in array foo..
>
>

    In   contrast   I  would  vote  for  adding  a  really  async
    functionality of the whole  frontend/backend  protocol.  That
    would  fit much better in the event driven world of graphical
    programs.


Until later, Jan

--

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