Thread: Where is PLbash ??
Hi, I am reading about PLbash in some of the mails and it seems to do exactly what I would like to get done. But where can I find it? Regards, Friedrich Dodt
Peter Eisentraut <peter_e@gmx.net> wrote it. I see: http://www.us.postgresql.org/interfaces.html point to a this page for it: http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html I would like to see this in our official distribution. --------------------------------------------------------------------------- Friedrich Dodt wrote: > > Hi, > > I am reading about PLbash in some of the mails and it seems to do > exactly what I would like to get done. > > But where can I find it? > > Regards, > Friedrich Dodt > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Hello, you point me to pgbash, but what I was looking for was called "PLbash". What I would like to do is to trigger a shell script from Postgres and from the description of pgbash I conclude that this won't be possible with this tool. I found PLbash mentioned as a solution for this problem in the mail: Re: making a trigger to a system call to a shell script by jm.poure@freesurf.fr at 3 May 2002 Also the mail Re: DataBlades by jm.poure@freesurf.fr at 16 Apr 2002 does mention PLbash. Any more hints? Regards Friedrich Dodt Bruce Momjian wrote: > > Peter Eisentraut <peter_e@gmx.net> wrote it. I see: > > http://www.us.postgresql.org/interfaces.html > > point to a this page for it: > > http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html > > I would like to see this in our official distribution. > > --------------------------------------------------------------------------- > > Friedrich Dodt wrote: > > > > Hi, > > > > I am reading about PLbash in some of the mails and it seems to do > > exactly what I would like to get done. > > > > But where can I find it? > > > > Regards, > > Friedrich Dodt > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: you can get off all lists at once with the unregister command > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
I thought I was sending you info about PLbash, but clearly it was pgbash, which is totally different. Peter Eisentraut <peter_e@gmx.net> is the autor. --------------------------------------------------------------------------- Friedrich Dodt wrote: > > Hello, > > you point me to pgbash, but what I was looking for was called "PLbash". > > What I would like to do is to trigger a shell script from Postgres and > from the description of pgbash I conclude that this won't be possible > with this tool. > > I found PLbash mentioned as a solution for this problem in the mail: > > Re: making a trigger to a system call to a shell script > by jm.poure@freesurf.fr at 3 May 2002 > > Also the mail > > Re: DataBlades > by jm.poure@freesurf.fr at 16 Apr 2002 > > does mention PLbash. > > Any more hints? > > Regards > Friedrich Dodt > > > Bruce Momjian wrote: > > > > Peter Eisentraut <peter_e@gmx.net> wrote it. I see: > > > > http://www.us.postgresql.org/interfaces.html > > > > point to a this page for it: > > > > http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html > > > > I would like to see this in our official distribution. > > > > --------------------------------------------------------------------------- > > > > Friedrich Dodt wrote: > > > > > > Hi, > > > > > > I am reading about PLbash in some of the mails and it seems to do > > > exactly what I would like to get done. > > > > > > But where can I find it? > > > > > > Regards, > > > Friedrich Dodt > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 2: you can get off all lists at once with the unregister command > > > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) > > > > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to majordomo@postgresql.org so that your > > message can get through to the mailing list cleanly > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian writes: > I thought I was sending you info about PLbash, but clearly it was > pgbash, which is totally different. Peter Eisentraut <peter_e@gmx.net> > is the autor. I have nothing to do with pgbash, but I have something to do with PL/sh, which is at or near http://www.postgresql.org/~petere/. -- Peter Eisentraut peter_e@gmx.net
Peter, can we add PL/sh into CVS for 7.3? --------------------------------------------------------------------------- Peter Eisentraut wrote: > Bruce Momjian writes: > > > I thought I was sending you info about PLbash, but clearly it was > > pgbash, which is totally different. Peter Eisentraut <peter_e@gmx.net> > > is the autor. > > I have nothing to do with pgbash, but I have something to do with PL/sh, > which is at or near http://www.postgresql.org/~petere/. > > -- > Peter Eisentraut peter_e@gmx.net > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Peter, can we add PL/sh into CVS for 7.3?
I'm kind of against adding PL/sh to CVS, ever; and I believe Peter is
too, else he'd have done it already.
I know you will say that PL/sh is not any more dangerous than the
untrusted versions of plperl and pltcl, but there is a difference.
PL/sh has *no reason to exist* other than to implement
non-transaction-safe outside-the-database behavior; there is no safe
behavior for which it is the preferred tool. I think making it easily
available is a bad idea, because people *will* shoot themselves in the
foot with it.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Peter, can we add PL/sh into CVS for 7.3? > > I'm kind of against adding PL/sh to CVS, ever; and I believe Peter is > too, else he'd have done it already. > > I know you will say that PL/sh is not any more dangerous than the > untrusted versions of plperl and pltcl, but there is a difference. > PL/sh has *no reason to exist* other than to implement > non-transaction-safe outside-the-database behavior; there is no safe > behavior for which it is the preferred tool. I think making it easily > available is a bad idea, because people *will* shoot themselves in the > foot with it. Well, sending an email is something only PL/sh can do. I don't see the point if we document when it should be used. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> I know you will say that PL/sh is not any more dangerous than the
>> untrusted versions of plperl and pltcl, but there is a difference.
>> PL/sh has *no reason to exist* other than to implement
>> non-transaction-safe outside-the-database behavior; there is no safe
>> behavior for which it is the preferred tool.
> Well, sending an email is something only PL/sh can do.
Nonsense --- a quick system() call in plperlu or pltclu can do it
just as well, or even launch a shell script if you insist on coding
your mistakes in sh...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> I know you will say that PL/sh is not any more dangerous than the > >> untrusted versions of plperl and pltcl, but there is a difference. > >> PL/sh has *no reason to exist* other than to implement > >> non-transaction-safe outside-the-database behavior; there is no safe > >> behavior for which it is the preferred tool. > > > Well, sending an email is something only PL/sh can do. > > Nonsense --- a quick system() call in plperlu or pltclu can do it > just as well, or even launch a shell script if you insist on coding > your mistakes in sh... Well, if they are going to call system() from perl, why don't we just give them PL/sh and they can do it directly. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Nonsense --- a quick system() call in plperlu or pltclu can do it
>> just as well, or even launch a shell script if you insist on coding
>> your mistakes in sh...
> Well, if they are going to call system() from perl, why don't we just
> give them PL/sh and they can do it directly.
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.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Nonsense --- a quick system() call in plperlu or pltclu can do it > >> just as well, or even launch a shell script if you insist on coding > >> your mistakes in sh... > > > Well, if they are going to call system() from perl, why don't we just > > give them PL/sh and they can do it directly. > > 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. Also, there must be some things you can do in PL/sh that aren't transaction problems. In my view, there are lots of people who need shell access from PostgreSQL, and they are naturally going to try to use PL/sh. When they do, we can explain the limitations. I don't see how not giving them PL/sh prevents them from doing transaction-unsafe things. Usually, people using PL/sh want to do something that is transaction-unsafe by nature. Also, there is a wiz-bang aspect to being able to do shell scripts in the backend that has a certain "marketing" value. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Hello Bruce, Tuesday, June 25, 2002, 2:54:06 PM, you wrote: BM> Well, sending an email is something only PL/sh can do. I don't see the Pl/Python, or PL/Perl can do it easily too (even without opening external processes I mean). PL/TCL certainly should do it too. ------------- Best regards,Steve Howe mailto:howe@carcass.dhs.org
On Tue, 2002-06-25 at 11:01, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > >> I know you will say that PL/sh is not any more dangerous than the > > >> untrusted versions of plperl and pltcl, but there is a difference. > > >> PL/sh has *no reason to exist* other than to implement > > >> non-transaction-safe outside-the-database behavior; there is no safe > > >> behavior for which it is the preferred tool. > > > > > Well, sending an email is something only PL/sh can do. > > > > Nonsense --- a quick system() call in plperlu or pltclu can do it > > just as well, or even launch a shell script if you insist on coding > > your mistakes in sh... > > Well, if they are going to call system() from perl, why don't we just > give them PL/sh and they can do it directly. > Humm, actually, I think you can send an email from straight Tcl (and probably Perl), without the system call (unless of course you wanted to interface with a specific mail agent). Look at pgmail for an example of this (pgmail.sf.net). --brett > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
Bruce Momjian <pgman@candle.pha.pa.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.
regards, tom lane
Steve Howe wrote: > > Hello Bruce, > > Tuesday, June 25, 2002, 2:54:06 PM, you wrote: > > BM> Well, sending an email is something only PL/sh can do. I don't see the > Pl/Python, or PL/Perl can do it easily too (even without opening > external processes I mean). PL/TCL certainly should do it too. > Well, PL/TclU can do set sm [socket localhost smtp] puts $sm "HELO PostgreSQL" ... close $sm Underneath eMail is still a telnet style protocol and well documented too. Noone needs a damned shell with all it's portability and security problems to generate a simple eMail notification. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Tom Lane writes: > I know you will say that PL/sh is not any more dangerous than the > untrusted versions of plperl and pltcl, but there is a difference. > PL/sh has *no reason to exist* other than to implement > non-transaction-safe outside-the-database behavior; there is no safe > behavior for which it is the preferred tool. What is the preferred way to implement non-database side effects, such as triggering emails when certain events occur? We should try to explain this somewhere. Certainly, PL/sh is not the preferred way. It's terribly inefficient and not nearly portable. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> What is the preferred way to implement non-database side effects, such as
> triggering emails when certain events occur? We should try to explain
> this somewhere.
> Certainly, PL/sh is not the preferred way. It's terribly inefficient and
> not nearly portable.
As Jan pointed out, either plperlu or pltclu can accomplish just about
anything you'd want in that line, even without the escape hatch of
firing a shell script.
I think Bruce has correctly identified a documentation deficiency:
there's not any material explaining the transaction-unsafety risks of
using these PLs to do stuff outside the database. We should talk
about that someplace.
My opinion is that the *preferred* way would involve having a background
client-side task that watches for things to do (eg via NOTIFY/LISTEN),
and then updates the database to indicate that it's done it. This
doesn't require any unsafe PL programming at all, but it does mean extra
work to set up a suitable client task. An example would make a great
contrib item ...
regards, tom lane
Tom Lane wrote: > [...] > 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. Adding an otherwise useless module to contrib just to have a place to put in a big red WARNING!!! Hmmm, I kinda like that :-) Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
On Tue, 25 Jun 2002, Tom Lane wrote: > My opinion is that the *preferred* way would involve having a background > client-side task that watches for things to do (eg via NOTIFY/LISTEN), > and then updates the database to indicate that it's done it. This > doesn't require any unsafe PL programming at all, but it does mean extra > work to set up a suitable client task. An example would make a great > contrib item ... I actually have implemented just that, but it requires patches to DBD::Pg to do a "wait until event happens". I'll dig it out and submit to contrib
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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. 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. 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Jan Wieck wrote: > Steve Howe wrote: > > > > Hello Bruce, > > > > Tuesday, June 25, 2002, 2:54:06 PM, you wrote: > > > > BM> Well, sending an email is something only PL/sh can do. I don't see the > > Pl/Python, or PL/Perl can do it easily too (even without opening > > external processes I mean). PL/TCL certainly should do it too. > > > > Well, PL/TclU can do > > set sm [socket localhost smtp] > puts $sm "HELO PostgreSQL" > ... > close $sm > > Underneath eMail is still a telnet style protocol and well documented > too. Noone needs a damned shell with all it's portability and security > problems to generate a simple eMail notification. So the people have to learn the SMTP protocol to send email. No wonder people say PostgreSQL is hard to learn. ;-) Some people just want to get the job done, and they will worry about performance later. The shell is a powerful way to do that. Why do we spend most of our time at shell prompts anyway? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, Jun 25, 2002 at 01:52:41PM -0400, Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Peter, can we add PL/sh into CVS for 7.3? > > I'm kind of against adding PL/sh to CVS, ever; and I believe Peter is > too, else he'd have done it already. > > I know you will say that PL/sh is not any more dangerous than the > untrusted versions of plperl and pltcl, but there is a difference. > PL/sh has *no reason to exist* other than to implement > non-transaction-safe outside-the-database behavior; there is no safe > behavior for which it is the preferred tool. I think making it easily > available is a bad idea, because people *will* shoot themselves in the > foot with it. :-) In my Debian is available a lot of non-safe programs and utils...I think people have own brain and if documentation warnabout PL/shit's enough. (BTW, default Apache distribution contains shell basedCGI script and people can write othersown shell scripts -- it'sinteresting, but people more use PHP/Perl/Python/etc. Why? Because they good know what isbetter/safe.) Karel -- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
> As Jan pointed out, either plperlu or pltclu can accomplish just about > anything you'd want in that line, even without the escape hatch of > firing a shell script. But if you can do it more easily with PL/sh why don't you? > > I think Bruce has correctly identified a documentation deficiency: > there's not any material explaining the transaction-unsafety risks of > using these PLs to do stuff outside the database. We should talk > about that someplace. Yes, please. See below. > > My opinion is that the *preferred* way would involve having a background > client-side task that watches for things to do (eg via NOTIFY/LISTEN), > and then updates the database to indicate that it's done it. This > doesn't require any unsafe PL programming at all, but it does mean extra > work to set up a suitable client task. An example would make a great > contrib item ... Well, I am one of those poor guys who live in the real world and just would like to (and have to) get their job done. In my case, I don't want to fire an email. We have an application server running on top of postgresql and we need a reliable method to trigger some action in the application server as soon as some table is changed by an external program. As far as I see the application server specification (here: EJB) doesn't provide for such a method that is guaranteed to not do a resource consuming polling. This is a typical instance of the often occuring problem that a higher level interface (EJB) isolates you from things you could have done easily on a lower level (postgres). Now, the solution I had in mind when I asked for PL/sh was to trigger a shell script that calls a tiny Java-program that calls a SessionBean in the EJB-Tier which in turn finds out what happened in the table. This is nasty, this is slow, but it does what I want to get done - and it prevents polling. In fact, before you told me where to find PL/sh, I wrote a small C procedure that forks the shell. Yes, I realized there is the NOTIFY/LISTEN possibility. But using this would cost me much more development time. And, later on, it will cost more administration effort. The point here is: How can I be safe that my LISTENing process is always up and running? That goes into the startup scripts, into the keepalive logic, and it requires a much more subtle testing. So, what is the weakness of my strategy? Is there a "transaction-unsafety risk" in this case? I would LIKE to learn more about this. The discussion of whether to include PL/sh into the Postgres-Distribution or not resembles a discussion of whether to have a knife in your kitchen. You can do a lot of useful things with a knife but you and your children can hurt themselves with it as well. What do you do then? You tell your children that a knife can be dangerous and you try to be careful yourself. If you overprotect your children they never get adult. - I mean treat your users as adults. If you don't recommend the tool don't put it into the distribution, but it would be nice if you put it somewhere where it can be found easily, needless to say with the appropriate warnings. Regards Friedrich Dodt
Friedrich Dodt <fdodt@web.de> writes:
> So, what is the weakness of my strategy? Is there a
> "transaction-unsafety risk" in this case?
Well, the most obvious point is that you're firing the notification off
before your own transaction has committed. The receiving process might
look at the table to see what to do, not find anything visible, and go
back to sleep before you are able to commit.
NOTIFY/LISTEN avoids this pitfall because the notify isn't sent until commit.
regards, tom lane
Bruce Momjian wrote: > > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.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@Yahoo.com #
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@candle.pha.pa.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@Yahoo.com # > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073