>
> 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)
Of course.
> I think it will also need:
> - global variable
> in a session context (standard mentions these also)
Might be good either. Thanks.
> > - 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.
PL/Tcl could be enhanced to do this too. Will make it in the
future.
> BTW.: How do you write an input or output function in pl/tcl if all you get
> is the external representation ?
Impossible.
>
> 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.
>
>
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) #
