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.

Search Discussions

  • Jan Wieck at Feb 23, 1998 at 12:20 pm

    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) #
  • Brett McCormick at Feb 23, 1998 at 1:00 pm
    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.
  • Ocie at Feb 23, 1998 at 8:15 pm

    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
  • Jan Wieck at Feb 23, 1998 at 8:45 pm

    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) #
  • Brett McCormick at Feb 23, 1998 at 9:22 pm
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 23, '98 at 11:12a
activeFeb 23, '98 at 9:22p
posts6
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase