From: | Zeugswetter Andreas SARZ <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
---|---|
To: | "'pgsql-hackers(at)hub(dot)org'" <pgsql-hackers(at)hub(dot)org> |
Subject: | Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru les (not instead)) |
Date: | 1998-02-23 11:11:52 |
Message-ID: | 219F68D65015D011A8E000006F8590C6010A51ED@sdexcsrv1.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Mattias Kregert | 1998-02-23 11:22:24 | Re: [HACKERS] Permissions on copy |
Previous Message | Brett McCormick | 1998-02-23 10:41:45 | Re: pl/{perl, pgsql} (was Re: AW: [HACKERS] triggers, views and rules (not instead)) |