Re: *****SPAM***** Re: if-clause to an exiting statement

From: Kobi Biton <kobi(at)comns(dot)co(dot)il>
To: Scott Ribe <scott_ribe(at)elevated-dev(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: *****SPAM***** Re: if-clause to an exiting statement
Date: 2010-12-07 18:18:56
Message-ID: 1291745936.17275.15.camel@kbiton-lap-ub
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I know it does not make sens "application bug" however consider the
following scenarion , looking at the Statement I sent I would like to
check if over the last 10 minutes a certain type of event was logged and
if NOT (row-count=0) then I would like to trigger and action.

hope it makes more sense.

Kobi.
On Tue, 2010-12-07 at 10:44 -0700, Scott Ribe wrote:
> On Dec 7, 2010, at 9:58 AM, Kobi Biton wrote:
> >
> > I know it does not sound logic however I do need to set the row count
> > to 1 in case row count returns 0
>
> Perhaps I didn't make myself clear: you can't do that. The only thing you can do is make sure your query returns a row, and in the case where it currently doesn't return a row I have absolutely no idea what it would be that you would need to return.
>
> If it would be acceptable to always return some hard-wired dummy row in addition to the 0 or more rows that match the current query, then you could use a UNION to add the dummy row to the selection. Otherwise, perhaps the real problem is that you do not have a matching event in the database and the real solution is to add such an event.
>
> In your original post you referred to an application bug where a trigger does not run if the row count is 0. It's hard for me to imagine how it's a bug to not take action when there is no event that needs processing...
>
> --
> Scott Ribe
> scott_ribe(at)elevated-dev(dot)com
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
>

--
Kobi Biton
Com N S Ltd.

Mobile: +972 (54) 8017668

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alban Hertroys 2010-12-07 18:20:08 Re: SELECT is immediate but the UPDATE takes forever
Previous Message Alban Hertroys 2010-12-07 18:17:50 Re: Hanging with pg_restore and large objects