Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru les (not instead))
Zeugswetter Andreas IZ5 <andreas.zeugswetter@telecom.at>
From: Zeugswetter Andreas SARZ <Andreas.Zeugswetter@telecom.at>
To: "'pgsql-hackers@hub.org'" <pgsql-hackers@hub.org>
Date: 1998-02-23T11:11:52Z
Lists: pgsql-hackers
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.