Well, the surprise for me is: this is exactly what I thought! I actually do
have a lot of string manipulation to do, but I am the only one on the team
with Tcl experience. For the sake of other developers I thought that the
plPHP project would be interesting, but I don't get the impression that it
is as well-developed as plTcl. Does anyone know anything about it?
Also, does anyone know why the plTcl was taken outof the core distribution?
Carlo
""Ian Harding"" <harding.ian@gmail.com> wrote in message
news:725602300608012014v6337f4d0r90c4c8dc3c25884a@mail.gmail.com...
> On 8/1/06, Christopher Browne <cbbrowne@acm.org> wrote:
>> Martha Stewart called it a Good Thing when "Carlo Stonebanks"
>> <cstonebanks@nissenfasteners.com> wrote:
>> > I am interested in finding out a "non-religious" answer to which
>> > procedural language has the richest and most robust implementation
>> > for Postgres. C is at the bottom of my list because of how much
>> > damage runaway code can cause. I also would like a solution which is
>> > platorm-independent; we develop on Windows but may deploy on Linux.
>>
>
>
>>
>> - Doing funky string munging using the SQL functions available in
>> pl/pgsql is likely to be painful;
>>
>> - Doing a lot of DB manipulation in pl/Perl or pl/Tcl or such
>> requires having an extra level of function manipulations that
>> won't be as natural as straight pl/pgsql.
>
> Another important distinguishing characteristic is whether it supports
> set returning functions. I think only plpgsql does right now.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
