Re: Partitioning and ORM tools
От | Adrian Klaver |
---|---|
Тема | Re: Partitioning and ORM tools |
Дата | |
Msg-id | 56F1C461.5000107@aklaver.com обсуждение исходный текст |
Ответ на | Re: Partitioning and ORM tools (CS DBA <cs_dba@consistentstate.com>) |
Ответы |
Re: Partitioning and ORM tools
Re: Partitioning and ORM tools |
Список | pgsql-general |
On 03/22/2016 02:20 PM, CS DBA wrote: > > > On 03/22/2016 03:18 PM, Rob Sargent wrote: >> >> >> On 03/22/2016 03:00 PM, Joshua D. Drake wrote: >>> On 03/22/2016 01:50 PM, CS DBA wrote: >>> >>>> Understood, was just wondering if there is a way to cause the child >>>> table insert results to be returned to the ORM/Application instead of >>>> the master/base table insert >>> >>> Insert into the child table directly based on the partition rules. >>> >>> JD >>> >>> >> I would think the ORM (as yet undefined) would want to think in terms >> of the parent table and not know about the physical schema details. >> Can the client not be written to check only for errors vs checking >> for non-zero inserts? >> >> >> > That was our first suggestion, they don;t want to make any app changes 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 > > > > -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: