Re: insert-select once more

From: will trillich <will(at)serensoft(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: insert-select once more
Date: 2001-04-17 16:10:44
Message-ID: 20010417111044.C13656@serensoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Apr 16, 2001 at 02:22:42PM +0200, Gyozo Papp wrote:
> 3) I created a rule to avoid the next process: "if there is already a row with the same vendor_id and c_date, make an UPDATE (to add the new hit count (NEW.c_num) to the saved one), but if it is missing the original INSERT will be executed."
> =# CREATE RULE r_logstat AS ON INSERT TO stat
> WHERE EXISTS (SELECT * FROM stat WHERE vendor_id = new.vendor_id AND c_date= new.c_date)
> DO INSTEAD UPDATE stat SET c_num = c_num + new.c_num WHERE vendor_id = new.vendor_id AND c_date= new.c_date;

that's a neat concept. in my mind <guess> the WHERE allows you to
position 'cursors' within various tables to get certain values
from them, before the rule takes hold.

--DROP RULE prof_insert;
CREATE RULE prof_insert AS
ON INSERT TO prof
WHERE
_faculty.who = get_whoid( NEW.login )
AND
_faculty.edu = get_eduid( NEW.educode )
DO INSTEAD
INSERT INTO _prof (
course,
who,
-- status,
editor
) VALUES (
get_courseid( NEW.educode, NEW.topiccode, NEW.coursecode, NEW.language, NEW.medium ),
_faculty.who, -- <<< specified via above WHERE clause
-- NEW.status,
NEW.editor
)
;

what that does, is get a _faculty.who pointer based on NEW.login
and NEW.educode; it does NOT tell postgres "if there is none,
then ignore this rule".

</guess> i think.

> 4) and now, the query:
> => INSERT INTO stat (vendor_id, c_date, c_num)
> SELECT vendor_id, current_date, count(*) FROM device WHERE [expressions select rows] GROUP BY vendor_id;
> and the result (if there is a row that should be rather updated):
> ERROR: ExecEvalAggref: no aggregates in this expression context
>
> If you execute the previous query twice against an originally empty table stat, you get this error for the second attempt.

which meshes with my theory. but i still could be wrong. :)

--
don't visit this page. it's bad for you. take my expert word for it.
http://www.salon.com/people/col/pagl/2001/03/21/spring/index1.html

will(at)serensoft(dot)com
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Travis Bauer 2001-04-17 16:10:52 Re: JDBC error in 7.0.3
Previous Message will trillich 2001-04-17 16:04:39 Re: Problem with function invocation