From: | Manuel Kniep <m(dot)kniep(at)web(dot)de> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | CS DBA <cs_dba(at)consistentstate(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Partitioning and ORM tools |
Date: | 2016-03-22 22:35:26 |
Message-ID: | 5E86725C-30C8-4E9D-80AD-DA4EDB54EE78@web.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> So the ORM is parsing the INSERT return value, correct?
>
> Would something like this(borrowing from docs example) freak it out?:
>
> CREATE OR REPLACE FUNCTION measurement_insert_trigger()
> RETURNS TRIGGER AS $$
> DECLARE
> _ct int;
> BEGIN
> INSERT INTO measurement_y2016m03 VALUES (NEW.*);
> SELECT INTO _ct count(NEW.*);
> RAISE NOTICE 'INSERT 0 %', _ct;
> RETURN NULL;
> END;
> $$
> LANGUAGE plpgsql;
>
> test=# insert into measurement values(1, '03/21/2016', 50, 87);
> NOTICE: INSERT 0 1
> INSERT 0 0
>
>
we had a similar problem using ruby and ActiveRecord and solved it with
RETURN NEW;
at the end of the insert trigger
which would result in inserting the row into the master table as well
that is then deleted right away in an AFTER INSERT trigger
CREATE OR REPLACE FUNCTION delete_master_trigger()
DECLARE
r master%rowtype;
BEGIN
DELETE FROM ONLY master WHERE id = NEW.id returning * into r;
RETURN r;
END;
$$
LANGUAGE plpgsql;
Returning the inserted row here also solves the problem that ORM often need auto increment values back.
regards
Manuel Kniep
From | Date | Subject | |
---|---|---|---|
Next Message | John R Pierce | 2016-03-23 01:49:37 | Re: Partitioning and ORM tools |
Previous Message | Manuel Kniep | 2016-03-22 22:34:06 | Re: Partitioning and ORM tools |