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

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

A plus for PL/perl -- you can write input/output functions with
pack/unpack..

On Mon, 23 February 1998, at 13:24:25, Jan Wieck wrote:

Jan Wieck wrote:

BTW.: How do you write an input or output function in pl/tcl if all you get
is the external representation ?

Impossible.

We could have the backend check file permissions, open the file and
pass the file pointer to the pl/tcl procedure. This sounds a bit
complicated I know. It seems to me that we would want at least a
"stdout" available to the procedure so that it can "talk to" the user.
If we provide stdin, stdout and stderr, then we could use redirection
to pipe input to and from a procedure.

Ocie Mitchell

Ocie Mitchell wrote:

Jan Wieck wrote:

BTW.: How do you write an input or output function in pl/tcl if all you get
is the external representation ?

Impossible.

We could have the backend check file permissions, open the file and
pass the file pointer to the pl/tcl procedure. This sounds a bit
complicated I know. It seems to me that we would want at least a
"stdout" available to the procedure so that it can "talk to" the user.
If we provide stdin, stdout and stderr, then we could use redirection
to pipe input to and from a procedure.

That's not the point. With input/output functions, the
postgres data types input/output registered procedures where
ment. That are the functions, that convert one Datum from
it's external string representation into and back from it's
internal binary value used in the database tuples.

Direct file access from inside a backends function is IMHO
never a good thing. This is the job of an application
program, because the actually accessed file might be on an
NFS filesystem, this can hang and the database backend will
hang inside of a transaction where maybe even the DBA or root
cannot kill them (process is blocked inside a system call).

This is IMHO a NONO.

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

I must chime in and agree strongly, but I also have a query: do the
pointers for HeapStruct (and related form struct) ever have to be
re-initialized using the cache lookup functions?

On Mon, 23 February 1998, at 21:49:48, Jan Wieck wrote: