pltcl_*mod commands are broken on Solaris 10

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 was found])

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. +