Thread: Can PostgreSQL notify a client that a trigger has fired?
Does PostgreSQL have built in mechanism I can use to conditionally notify a client application that a trigger has fired? What I want is something along the line of the following pseudo code in a trigger. if <condition> then raise client event -- .Bill.
On Thu, 2006-11-09 at 00:39 +0000, Bill wrote:
> Does PostgreSQL have built in mechanism I can use to conditionally
> notify a client application that a trigger has fired? What I want is
> something along the line of the following pseudo code in a trigger.
>
> if <condition> then
> raise client event
>
Yes, use LISTEN and NOTIFY. Probably it's easiest to write the trigger
in PL/pgSQL.
Regards,
Jeff Davis
"Bill" <postgresql@dbginc.com> writes: > Does PostgreSQL have built in mechanism I can use to conditionally > notify a client application that a trigger has fired? What I want is > something along the line of the following pseudo code in a trigger. > > if <condition> then > raise client event I have the impression that you're missing a lot of sections in the manual... How about some time to re-read it? http://www.postgresql.org/docs/8.1/interactive/sql-notify.html -- Jorge Godoy <jgodoy@gmail.com>
Jorge Godoy wrote: > I have the impression that you're missing a lot of sections in the > manual... How about some time to re-read it? I don't know about you but for me a 1500 page manual is at least two weeks of full time reading.<g> I have read several sections of it but I am trying to decide if PostgreSQL should be considered for a project and I don't have 80 hours to make the evaluation. As well indexed as the manual is, there are some topics I cannot find without knowing the PostgreSQL specific terminology. That's one of the great things about newsgroups and mailing lists; you can get help with specific questions from experienced users. I appreciate all the anwers I have received here. They have made it possible for me to do a much better job in the time available. My thanks to everyone. -- .Bill.
Bill wrote: > Jorge Godoy wrote: > >> I have the impression that you're missing a lot of sections in the >> manual... How about some time to re-read it? > > I don't know about you but for me a 1500 page manual is at least two > weeks of full time reading.<g> I have read several sections of it but I > am trying to decide if PostgreSQL should be considered for a project > and I don't have 80 hours to make the evaluation. If you don't have 80 hours to evaluate a new database, I'd suggest sticking with whatever you're already familiar with. You only have to hit a couple of minor problems with your implementation to consume more than 80 hours. If you're up against timescales that short, then stick to technologies you already know front-to-back. -- Richard Huxton Archonet Ltd
"Bill" <postgresql@dbginc.com> writes: > Jorge Godoy wrote: > >> I have the impression that you're missing a lot of sections in the >> manual... How about some time to re-read it? > > I don't know about you but for me a 1500 page manual is at least two > weeks of full time reading.<g> I have read several sections of it but I It took me 5s to type "postgresql notify" (all words from the subject) at Google and choose the first link I got from the answer. I don't see how this compare to reading 1500 pages manuals page by page. Anyway, just ignore this kind of answer if you wish. I just believe that you'll miss much more than what you'll get if you don't see the whole picture. -- Jorge Godoy <jgodoy@gmail.com>
On Thu, 2006-11-09 at 10:16 +0000, Richard Huxton wrote:
> Bill wrote:
> > Jorge Godoy wrote:
> >
> >> I have the impression that you're missing a lot of sections in the
> >> manual... How about some time to re-read it?
> >
> > I don't know about you but for me a 1500 page manual is at least two
> > weeks of full time reading.<g> I have read several sections of it but I
> > am trying to decide if PostgreSQL should be considered for a project
> > and I don't have 80 hours to make the evaluation.
>
> If you don't have 80 hours to evaluate a new database, I'd suggest
> sticking with whatever you're already familiar with. You only have to
> hit a couple of minor problems with your implementation to consume more
> than 80 hours. If you're up against timescales that short, then stick to
> technologies you already know front-to-back.
>
If we turn away everyone who was "trying to decide if PostgreSQL should
be considered", I think that we're failing in the advocacy department.
It may be just a preliminary analysis to see which databases claim to
meet the application's requirements. Perhaps he doesn't already have a
team of DBAs that know any RDBMS front-to-back.
I think he should consider PostgreSQL, and try to find out if it is a
possible solution for his application. Asking questions on -general or
IRC, in addition to googling the docs, are probably the best way to get
answers to his questions quickly. It took me a long time before I really
understood where to find things in the docs very quickly*. And just like
mathematics, sometimes asking the question out loud answers itself :)
However, you're right. If Bill is already familiar with one product,
it's probably a mistake to jump blind into any new RDBMS on an important
project; and that includes the world's most advanced open source
database. He should see if it looks good, then evaluate and test it as
thoroughly as he would any other RDBMS.
Regards,
Jeff Davis
* The docs are great, but it's a complex subject, everything's inter-
related, and the words you're looking for aren't always obvious.
Jeff Davis wrote: > On Thu, 2006-11-09 at 10:16 +0000, Richard Huxton wrote: >> Bill wrote: >>> Jorge Godoy wrote: >>> >>>> I have the impression that you're missing a lot of sections in the >>>> manual... How about some time to re-read it? >>> I don't know about you but for me a 1500 page manual is at least two >>> weeks of full time reading.<g> I have read several sections of it but I >>> am trying to decide if PostgreSQL should be considered for a project >>> and I don't have 80 hours to make the evaluation. >> If you don't have 80 hours to evaluate a new database, I'd suggest >> sticking with whatever you're already familiar with. You only have to >> hit a couple of minor problems with your implementation to consume more >> than 80 hours. If you're up against timescales that short, then stick to >> technologies you already know front-to-back. > > If we turn away everyone who was "trying to decide if PostgreSQL should > be considered", I think that we're failing in the advocacy department. True enough. But its better he use something else than have a bad experience with PG. Look at how long the "difficult to install" story hung around after the 6.5 days (when it was too fiddly to be fair). > It may be just a preliminary analysis to see which databases claim to > meet the application's requirements. Perhaps he doesn't already have a > team of DBAs that know any RDBMS front-to-back. Part of what was worrying me was Bill was asking a series of small questions. Of course he's not to know that the PG lists are among the best on the 'net and he's probably trying to keep his questions specific and answerable (which they were). > However, you're right. If Bill is already familiar with one product, > it's probably a mistake to jump blind into any new RDBMS on an important > project; I'm sure we've all done it, either from enthusiasm or management diktat. Invariably I've regretted trying to do something new with new (to me) technology. > * The docs are great, but it's a complex subject, everything's inter- > related, and the words you're looking for aren't always obvious. The .pgpass file is my favourite. I can see how it's part of the libpq chapter, but I'd always have to spend an hour trying to remember that fact. -- Richard Huxton Archonet Ltd