Thread: 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)
    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.

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

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

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