Re: Untrusted PL/Tcl? - Mailing list pgsql-hackers

From JanWieck@t-online.de (Jan Wieck)
Subject Re: Untrusted PL/Tcl?
Date
Msg-id 200007191249.OAA04861@hot.jw.home
Whole thread Raw
In response to Re: Untrusted PL/Tcl?  (JanWieck@t-online.de (Jan Wieck))
List pgsql-hackers
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
mightnot 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
anotherDB - not bad for a   first test. Socket operations (to GET an  html  page)  worked   too, so a PG backend can be
aweb-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 #




pgsql-hackers by date:

Previous
From: Pavel.Janik@linux.cz (Pavel Janík ml.)
Date:
Subject: Re: Re: pg_dump with BLOBS & V7.0.2 UPDATED
Next
From: Peter Vazsonyi
Date:
Subject: Re: MySQL comparison