Thread
-
Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru les (not instead))
Zeugswetter Andreas IZ5 <andreas.zeugswetter@telecom.at> — 1998-02-23T11:11:52Z
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. -
Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru
Jan Wieck <jwieck@debis.com> — 1998-02-23T12:24:25Z
> > 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) # -
Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru
Brett McCormick <brett@work.chicken.org> — 1998-02-23T13:00:34Z
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. > > > >
-
Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru
ocie@paracel.com — 1998-02-23T20:15:11Z
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
-
Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru
Jan Wieck <jwieck@debis.com> — 1998-02-23T20:49:48Z
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) # -
Re: pl/{perl,pgsql} (was Re: AW: [HACKERS] triggers, views and ru
Brett McCormick <brett@work.chicken.org> — 1998-02-23T21:22:30Z
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.