Thread: pltcl_*mod commands are broken on Solaris 10
Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on Solaris 10,
because there is not present tclsh. Unfortunately build process substitute path
to shell with empty string which invokes infinite loop.
See diff between S10 and Nevada:
bash-3.00# head /usr/postgres/8.3/bin/pltcl_listmod
#! /bin/sh
# $PostgreSQL: pgsql/src/pl/tcl/modules/pltcl_listmod.in,v 1.3 2006/03/11
04:38:40 momjian Exp $
#
# Start tclsh \
exec "$0" "$@"
---------------------------------------------------------
bash-3.2$ head pltcl_listmod
#! /bin/sh
# $PostgreSQL: pgsql/src/pl/tcl/modules/pltcl_listmod.in,v 1.3 2006/03/11
04:38:40 momjian Exp $
#
# Start tclsh \
exec /usr/bin/tclsh "$0" "$@"
By main opinion main problem is in build process which does not fail and also
dependency on tclsh is hidden by exec command.
Any idea how to fix it? Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
Zdenek Kotala napsal(a):
> Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on
> Solaris 10, because there is not present tclsh.
I found that tclsh is available on solaris 10 in /usr/sfw/bin and its name is
tclsh8.3.
Zdenek
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on Solaris 10,
> because there is not present tclsh.
Shouldn't this bug be filed against Solaris' clearly-broken tcl
installation?
regards, tom lane
Tom Lane napsal(a): > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: >> Commands pltcl_listmod, pltcl_delmod, pltcl_loadmod does not work on Solaris 10, >> because there is not present tclsh. > > Shouldn't this bug be filed against Solaris' clearly-broken tcl > installation? > I'm not able to make decision if tcl installation is broken on Solaris 10. tclsh is there but it is call tclsh8.3 and symbolic link is not there. But problem is also in configure which does not fail when tclsh is not found. I'm able to fix it on build machine to specify TCLSH environment variable, but still configure should be fixed. Zdenek -- Zdenek Kotala Sun Microsystems Prague, Czech Republic http://sun.com/postgresql
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> But problem is also in configure which does not fail when tclsh is not
> found.
Yes it does ...
if test $[#] -eq 0; then test -z "$TCLSH" && AC_MSG_ERROR([unable to locate tclConfig.sh because no Tcl shell
wasfound])
regards, tom lane
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> But problem is also in configure which does not fail when tclsh is not
>> found.
>
> Yes it does ...
>
> if test $[#] -eq 0; then
> test -z "$TCLSH" && AC_MSG_ERROR([unable to locate tclConfig.sh because no Tcl shell was found])
>
Yeah, I looked deeply on our solaris build script and problem is with following
configure setup:
./configure --prefix=/tmp/pg --with-tcl --with-tclconfig=/usr/sfw/lib
It found tclconfig, but not tclsh
...
checking for tclsh... no
checking for tcl... no
checking for tclConfig.sh... /usr/sfw/lib/tclConfig.sh
...
and configure finish successfully but plttcl_* scripts are broken.
If I define TCLSH env variable it seems to me be OK.
...
checking for tclsh... /usr/sfw/bin/tclsh8.3
checking for tclConfig.sh... /usr/sfw/lib/tclConfig.sh
...
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
Tom Lane wrote: > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > >> But problem is also in configure which does not fail when tclsh is not >> found. >> > > Yes it does ... > > if test $[#] -eq 0; then > test -z "$TCLSH" && AC_MSG_ERROR([unable to locate tclConfig.sh because no Tcl shell was found]) > > > > Does that happen if you specify the location of tclConfig.sh? I assume it usually knows where tclsh is, but the pltcl utilities won't. cheers andrew
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Yeah, I looked deeply on our solaris build script and problem is with following
> configure setup:
> ./configure --prefix=/tmp/pg --with-tcl --with-tclconfig=/usr/sfw/lib
> It found tclconfig, but not tclsh
Ah. So actually there is a bug in our configure: if you've set
--with-tcl, and it fails to find tclsh, it should error out instead
of allowing an incorrect path to be substituted into the pltcl_*mod
scripts. The configure code is assuming that the only thing it
really needs tclsh for is to find tclConfig.sh, but that's not so.
regards, tom lane
Am Tuesday, 22. July 2008 schrieb Tom Lane: > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > > Yeah, I looked deeply on our solaris build script and problem is with > > following configure setup: > > > > ./configure --prefix=/tmp/pg --with-tcl --with-tclconfig=/usr/sfw/lib > > > > It found tclconfig, but not tclsh > > Ah. So actually there is a bug in our configure: if you've set > --with-tcl, and it fails to find tclsh, it should error out instead > of allowing an incorrect path to be substituted into the pltcl_*mod > scripts. The configure code is assuming that the only thing it > really needs tclsh for is to find tclConfig.sh, but that's not so. Yeah, the configure code was orignally set up to find Tcl linking information, and it does so either by running tclsh or taking the tclConfig.sh file. That was all; no tclsh was actually necessary. The fact that the pltcl_*mod programs use the discovered tclsh setting as well was most likely an afterthought that was not made fully robust in the fact of all the ways that configure could be called. By the way, these programs start with package require Pgtcl but we don't provide that library. Should that bother us?
Peter Eisentraut <peter_e@gmx.net> writes:
> By the way, these programs start with
> package require Pgtcl
> but we don't provide that library. Should that bother us?
Hmm. The scripts actually depend on both pltcl and Pgtcl, so just
pushing them out to the Pgtcl package wouldn't really improve matters.
I think it's fine to leave them where they are ... though we should
document the dependency.
Actually it looks like it's been a very long time since these scripts
got any love anyway. There's no reason anymore to split modules into
multiple rows (not since TOAST...) and they're not schema-safe either.
Anybody feel like cleaning them up? Or should we leave 'em as-is
for compatibility reasons?
regards, tom lane
Tom Lane napsal(a): > Peter Eisentraut <peter_e@gmx.net> writes: >> By the way, these programs start with >> package require Pgtcl >> but we don't provide that library. Should that bother us? > > Hmm. The scripts actually depend on both pltcl and Pgtcl, so just > pushing them out to the Pgtcl package wouldn't really improve matters. > I think it's fine to leave them where they are ... though we should > document the dependency. > > Actually it looks like it's been a very long time since these scripts > got any love anyway. There's no reason anymore to split modules into > multiple rows (not since TOAST...) and they're not schema-safe either. > Anybody feel like cleaning them up? Or should we leave 'em as-is > for compatibility reasons? Just a dumb question, does we need this functionality? Does anybody use it? Zdenek
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> Tom Lane napsal(a):
>> Actually it looks like it's been a very long time since these scripts
>> got any love anyway. There's no reason anymore to split modules into
>> multiple rows (not since TOAST...) and they're not schema-safe either.
>> Anybody feel like cleaning them up? Or should we leave 'em as-is
>> for compatibility reasons?
> Just a dumb question, does we need this functionality? Does anybody use it?
Well, autoloading Tcl scripts is an extremely standard thing to do in
the Tcl world. It makes sense to me for pltcl to provide a way of
autoloading code out of the database instead of some random search path
or other --- particularly for trusted pltcl, which shouldn't allow
access to the server filesystem at all.
Whether these particular scripts are the best possible implementation of
the concept is another argument, of course. But I wouldn't agree with
just ripping 'em out. Note that my complaints above don't bear on
functionality, at least not unless someone is working in an environment
where the search_path varies a lot. So the lack of maintenance effort
doesn't indicate that they're not getting used.
regards, tom lane
Am Tuesday, 22. July 2008 schrieb Zdenek Kotala: > By main opinion main problem is in build process which does not fail and > also dependency on tclsh is hidden by exec command. Fixed. Now, configure will fail if no tcl shell is found. You can specify one with the TCLSH variable.
Peter Eisentraut napsal(a):
> Am Tuesday, 22. July 2008 schrieb Zdenek Kotala:
>> By main opinion main problem is in build process which does not fail and
>> also dependency on tclsh is hidden by exec command.
>
> Fixed. Now, configure will fail if no tcl shell is found. You can specify
> one with the TCLSH variable.
Thanks. Is it fixed only on head or do you plan to backported to older branch as
well?
Thanks Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> Tom Lane napsal(a):
>>> Actually it looks like it's been a very long time since these scripts
>>> got any love anyway. There's no reason anymore to split modules into
>>> multiple rows (not since TOAST...) and they're not schema-safe either.
>>> Anybody feel like cleaning them up? Or should we leave 'em as-is
>>> for compatibility reasons?
>
>> Just a dumb question, does we need this functionality? Does anybody use it?
>
> Well, autoloading Tcl scripts is an extremely standard thing to do in
> the Tcl world. It makes sense to me for pltcl to provide a way of
> autoloading code out of the database instead of some random search path
> or other --- particularly for trusted pltcl, which shouldn't allow
> access to the server filesystem at all.
I see.
> Whether these particular scripts are the best possible implementation of
> the concept is another argument, of course. But I wouldn't agree with
> just ripping 'em out. Note that my complaints above don't bear on
> functionality, at least not unless someone is working in an environment
> where the search_path varies a lot. So the lack of maintenance effort
> doesn't indicate that they're not getting used.
I understand. However I have another dumb idea/question - It seems to me that it
is client code. I think that it should be integrated into psql command. It has
several advantages - remove dependency on tclsh, remove tree commands, works
fine on system where tcl is not present.
thanks Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
> I understand. However I have another dumb idea/question - It seems to me that it
> is client code. I think that it should be integrated into psql
> command.
That doesn't seem like a particularly appropriate thing to do ... nor
do I see the argument for calling it client-side code.
regards, tom lane
Am Wednesday, 23. July 2008 schrieb Zdenek Kotala: > Is it fixed only on head or do you plan to backported to older branch as > well? I don't see a need to backport this. The only difference is that now you will get an error if no tclsh is found. The call "configure TCLSH=..." is the same in all versions.
Tom Lane napsal(a):
> Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes:
>> I understand. However I have another dumb idea/question - It seems to me that it
>> is client code. I think that it should be integrated into psql
>> command.
>
> That doesn't seem like a particularly appropriate thing to do ... nor
> do I see the argument for calling it client-side code.
>
I think that best thing at this moment is to add item to the TODO list about
cleanup.
Zdenek
--
Zdenek Kotala Sun Microsystems
Prague, Czech Republic http://sun.com/postgresql
Zdenek Kotala wrote: > Tom Lane napsal(a): > > Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > >> I understand. However I have another dumb idea/question - It seems to me that it > >> is client code. I think that it should be integrated into psql > >> command. > > > > That doesn't seem like a particularly appropriate thing to do ... nor > > do I see the argument for calling it client-side code. > > > > I think that best thing at this moment is to add item to the TODO list about > cleanup. I can add a TODO item but I am unsure anyone really cares --- seeing how long it took us to realize the poor state of the code. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +