Re: Where is PLbash ??

Well, with little support to add PL/Bash to our standard distribution, I
am removing this from the TODO:

o Add plsh server-side shell language (Peter E)

I personally think that having a shell script language in the backend by
default is a neat feature, and when used sparingly, very useful.
However, there is too much concern about performance problems. The
proposed solution to use NOTIFY to some client waiting for notifications
is certainly a more efficient solution, but more involved to configure.

Also, someone already pointed out that you can call Unix commands from
plperl and pltcl already.

---------------------------------------------------------------------------

Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > Tom Lane wrote:
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > > Tom Lane wrote:
> > > >> There's a difference between making a dangerous thing possible and
> > > >> encouraging people to do it. But I'll wait and see what Peter thinks.
> > >
> > > > I think Peter agrees with you. My point is that we can PL/sh and
> > > > document it's limitations. With perl, the ability is there but it isn't
> > > > obviouis why it is a problem.
> > >
> > > Well, there's some merit in that argument: the pl/sh chapter would be an
> > > ideal place to explain in bright red letters why pl/sh is dangerous ;-),
> > > and then we could cross-reference that discussion from plperlu and
> > > pltclu, which don't really have good places to put a long discussion
> > > about the risks.
> >
> > All I know is that from a shell I can do:
> >
> > echo "You lost money" | mail -s "Lost money" fred
> >
> > pretty easily. Hard to make anything simpler that that, and I can't
> > imagine the other languages are any faster or simpler.
>
> http://sourceforge.net/projects/pgmail/
>
> > I think sending email is an archetypal stored procedure action. I
> > realize it isn't great, but it meets people's needs who have to do it.
>
> I agree with Tom though, that this should be some kind of general client
> task using a NOTIFY mechanism. This mechanism needs two parts, a
> function that schedules the action putting the required info for the
> client into some tables, then notifies. And respective functionality in
> the client, that then performs these tasks and returs execution results
> into the database.
>
> > You can argue that people shouldn't want to do such things, but they
> > obviously want to do them, so why not give them a way, and warn them at
> > the same time.
>
> They want them, sure. But if you want to satisfy their wishes, give them
> a tool, not a dangerous kludge.
>
>
> 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 #
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073