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

From Mikhail Terekhov
Subject Re: Untrusted PL/Tcl?
Date
Msg-id 3975FC21.DD43F1F0@emc.com
Whole thread Raw
In response to Re: Untrusted PL/Tcl?  (JanWieck@t-online.de (Jan Wieck))
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: btree split logic is fragile in the presence of lar ge index items
Next
From: Peter Eisentraut
Date:
Subject: About these IPC parameters