Re: Partitioning and ORM tools

Поиск
Список
Период
Сортировка
От Manuel Kniep
Тема Re: Partitioning and ORM tools
Дата
Msg-id 227150FC-8739-4BD5-8B5F-F14B96958D7D@adeven.com
обсуждение исходный текст
Ответ на Re: Partitioning and ORM tools  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список 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




В списке pgsql-general по дате отправления:

Предыдущее
От: Manuel Kniep
Дата:
Сообщение: Re: Partitioning and ORM tools
Следующее
От: John R Pierce
Дата:
Сообщение: Re: Partitioning and ORM tools