Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru les (not instead))

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.

Responses

Browse pgsql-hackers by date

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