Jan, I think you describe the correct picture of what is needed for
PL/pgSQL.
My comments:
> No actual development - just have something in mind how I
> would implement it. I'll get into details after 6.3 release.
> PL/pgSQL will have at least the following capabilities:
>
> - local variable
local to the procedure (in a per call context)
I think it will also need:
- global variable
in a session context (standard mentions these also)
> - local records
> - access to the database over SPI
> - control structures (if/else/while/loop)
> - elog messages
> - triggers can modify new tuple
> - triggers can skip operation
>
> If perl doesn't have such a restricted interpreter facility,
> then perl might never become a TRUSTED procedural language
> like Tcl is.
There is taintperl.
I don't see anything that speaks against 2 variants of pl/perl. One trusted,
using taintperl
and one untrusted opening the internals to superusers, like in C.
BTW.: How do you write an input or output function in pl/tcl if all you get
is the external representation ?
Andreas
P.S.: there is no need to email me directly, unless you need something very
fast,
since I do read all pgsql-hackers mail in the digest. Thanx all.
