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