Hi all,

    there  have  been a couple of questions WRT doing untrustable
    things like file access, LDAP and the  like  from  inside  of
    triggers or functions.

    Tcl  is  a  powerful  language and could do all that, but the
    interpreter used in PL/Tcl is a safe one,  because  it  is  a
    trusted  procedural  language  (any  non-superuser can create
    functions). I think it should  be  pretty  easy  to  build  a
    second   PL  handler  into  the  module,  that  executes  the
    procedures in a full featured Tcl interpreter, that  has  all
    capabilities. This one would be installed as an untrusted PL,
    so  only  DB  superusers  could  create  functions  in   that
    language.

    Should  I  go  for  it and if so, how should this language be
    named?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Tue, 18 Jul 2000 13:36:22 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Untrusted PL/Tcl?
Jan Wieck wrote:
>     capabilities. This one would be installed as an untrusted PL,
>     so  only  DB  superusers  could  create  functions  in   that
>     language.
 
>     Should  I  go  for  it and if so, how should this language be
>     named?

Yes; pl/utcl.  Or pl/tclu. :-)  Those facilities would be nice to have.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 18 Jul 2000 07:54:41 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: Untrusted PL/Tcl?
JanWieck@t-online.de (Jan Wieck) writes:
>     Should  I  go  for  it and if so, how should this language be
>     named?

Sounds like a fine idea.

While you're in there, do you want to do something about supporting NULL
inputs and results properly?  Right now, a NULL input comes into a pltcl
function as an empty string, which is OK as far as it goes but you can't
always tell that from a valid data value.  There should be an inquiry
function to tell whether argument N is-null or not.  Also, AFAICT
there's no way for a pltcl function to return a NULL.  The most natural
Tcl syntax for this would be something like
	return -code null
but I'm not sure how hard it is to persuade the Tcl interpreter to
accept a new "-code" keyword without actually changing the Tcl core.
Worst-case, we could invent a new statement "return_null" ...

			regards, tom lane

Tue, 18 Jul 2000 10:52:20 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Untrusted PL/Tcl? 
Tom Lane wrote:
> JanWieck@t-online.de (Jan Wieck) writes:
> >     Should  I  go  for  it and if so, how should this language be
> >     named?
>
> Sounds like a fine idea.
>
> While you're in there, do you want to do something about supporting NULL
> inputs and results properly?  Right now, a NULL input comes into a pltcl
> function as an empty string, which is OK as far as it goes but you can't
> always tell that from a valid data value.  There should be an inquiry
> function to tell whether argument N is-null or not.  Also, AFAICT
> there's no way for a pltcl function to return a NULL.  The most natural
> Tcl syntax for this would be something like
>    return -code null
> but I'm not sure how hard it is to persuade the Tcl interpreter to
> accept a new "-code" keyword without actually changing the Tcl core.
> Worst-case, we could invent a new statement "return_null" ...

    Good  idea! I think I could add a -code null by replacing the
    builtin "return" function by a custom one.

    While beeing in there, I could do something else too I wanted
    to  do  for some time now. It'll break backward compatibility
    to Tcl versions prior to 8.0, so if there are objections  ...

    Beginning  with Tcl 8.0, dual ported objects got used to deal
    with values. These have (amongst performance issues) alot  of
    benefits.  Changing  all  the  call  interfaces would make it
    impossible to use PL/Tcl with a  pre  8.0  Tcl  installation.
    Since  we're  now  at Tcl 8.3 (the last I've seen), ISTM it's
    not a bad decision to force the upgrade.

    Comments?


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Tue, 18 Jul 2000 18:33:06 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Re: Untrusted PL/Tcl?
JanWieck@t-online.de (Jan Wieck) writes:
>     While beeing in there, I could do something else too I wanted
>     to  do  for some time now. It'll break backward compatibility
>     to Tcl versions prior to 8.0, so if there are objections  ...

>     Beginning  with Tcl 8.0, dual ported objects got used to deal
>     with values. These have (amongst performance issues) alot  of
>     benefits.  Changing  all  the  call  interfaces would make it
>     impossible to use PL/Tcl with a  pre  8.0  Tcl  installation.
>     Since  we're  now  at Tcl 8.3 (the last I've seen), ISTM it's
>     not a bad decision to force the upgrade.

OK by me.  Tcl 7.6 is getting to be ancient history... and people
who are using pltcl for database functions are probably going to
want all the speed they can get, so making a more efficient interface
to Tcl 8 seems like a good idea.

			regards, tom lane

Tue, 18 Jul 2000 16:55:01 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Untrusted PL/Tcl? 
Jan Wieck wrote:
> Tom Lane wrote:
> > JanWieck@t-online.de (Jan Wieck) writes:
> > >     Should  I  go  for  it and if so, how should this language be
> > >     named?
> >
> > Sounds like a fine idea.
> >
> > While you're in there, do you want to do something about supporting NULL
> > inputs and results properly?  Right now, a NULL input comes into a pltcl
> > function as an empty string, which is OK as far as it goes but you can't
> > always tell that from a valid data value.  There should be an inquiry
> > function to tell whether argument N is-null or not.  Also, AFAICT
> > there's no way for a pltcl function to return a NULL.  The most natural
> > Tcl syntax for this would be something like
> >    return -code null
> > but I'm not sure how hard it is to persuade the Tcl interpreter to
> > accept a new "-code" keyword without actually changing the Tcl core.
> > Worst-case, we could invent a new statement "return_null" ...
>
>     Good  idea! I think I could add a -code null by replacing the
>     builtin "return" function by a custom one.

    Well,  I've  implemented  an  "argisnull n" and "return_null"
    command for now. So "argisnull 1" will tell if $1 is NULL  or
    not.

    The  "return -code null" would be theoretically possible. But
    it might make us more Tcl version dependant  than  we  really
    want to be.

>     While beeing in there, I could do something else too I wanted
>     to  do  for some time now. It'll break backward compatibility
>     to Tcl versions prior to 8.0, so if there are objections  ...
>
>     Beginning  with Tcl 8.0, dual ported objects got used to deal

    Something  I  had to reevaluate. All values exchanged between
    PG  and  Tcl  have  to   go   through   the   type   specific
    input-/output-functions.  So  Tcl is dealing with strings all
    the time. Therefore, the dual ported objects might not do for
    us,  what  they  usually do for an application. Left it as is
    for now.

    PL/TclU (pltclu) is in place now. I think I'll like it :-)

    There's just one nasty detail. If an untrusted function wants
    to   load   other  binary  Tcl  modules,  it  needs  to  load
    libtcl8.0.so explicitly first (to avoid unresolved  symbols).
    But   after   that,  I  was  able  to  load  libpgtcl.so  and
    connect/query another  database  on  the  first  try!   A  DB
    backend  that  acts as a client on another DB - not bad for a
    first test. Socket operations (to GET an  html  page)  worked
    too, so a PG backend can be a web-browser now :-).


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



Wed, 19 Jul 2000 14:49:24 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Re: Untrusted PL/Tcl?
Jan Wieck wrote:
> 
> Mikhail Terekhov wrote:
> >
> > Do you plan to make libpgtcl stubs enabled? In this case it would be
> > possible to use any version of tcl, at least any 8.*>8.05. It seems that
> > this is not hard to do, see http://dev.scriptics.com/doc/howto/stubs.html
> 
>     Seems you mixed up some things here.
> 
>     PL/Tcl  is  a  "procedural  language"  living  inside  of the
>     database backend. One can write DB-side functions and trigger
>     procedures  using  it, and they are executed by the DB server
>     process itself during query execution.
> 
>     These functions have a total different  interface  to  access
>     the DB they are running inside already.

Ok
 
>     This  all  has  nothing  to  do with a Tcl script accessing a
>     Postgres database  as  a  client  application.  It's  totally
>     unrelated  to libpgtcl! Even if the changes I committed today

Right

>     enable a  backend,  executing  a  PL/TclU  (a  new  language)
>     function,  to  become  the  client  of another database using
>     libpgtcl now - to make the confusion perfect.
> 

PL/Tcl and libpqtcl have one important thing in common - they use 
Tcl library. The purpose of stubs mechanism is to make applications
which use Tcl library independent from the Tcl version as much as
possible. The bottom line is that if you want your PL/Tcl or PL/TclU
or libpgtc to be linked with the Tcl dynamically, then there is a 
possibility that due to version mismatch they will not work after
upgradig/downgrading Tcl. So it is better to use stubs to avoid this.

Mikhail

Wed, 19 Jul 2000 15:06:09 -0400
Mikhail Terekhov <terekhov@emc.com>
Re: Untrusted PL/Tcl?