Re: Untrusted PL/Tcl?

From: JanWieck(at)t-online(dot)de (Jan Wieck)
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL HACKERS <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Untrusted PL/Tcl?
Date: 2000-07-18 16:33:06
Message-ID: 200007181633.SAA11665@hot.jw.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> JanWieck(at)t-online(dot)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(at)Yahoo(dot)com #

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-07-18 18:18:14 Shared library search paths
Previous Message Magnus Hagander 2000-07-18 16:21:23 RE: FlushRelationBuffers returned -2