Re: Untrusted PL/Tcl?

From: Mikhail Terekhov <terekhov(at)emc(dot)com>
To:
Cc: PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Untrusted PL/Tcl?
Date: 2000-07-19 19:06:09
Message-ID: 3975FC21.DD43F1F0@emc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-07-19 22:46:01 Re: Shared library search paths
Previous Message Tom Lane 2000-07-19 18:13:48 Re: btree split logic is fragile in the presence of lar ge index items