Re: Partitioning and ORM tools - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Partitioning and ORM tools
Date
Msg-id 56F1C461.5000107@aklaver.com
Whole thread Raw
In response to Re: Partitioning and ORM tools  (CS DBA <cs_dba@consistentstate.com>)
Responses Re: Partitioning and ORM tools  (Manuel Kniep <m.kniep@web.de>)
Re: Partitioning and ORM tools  (Manuel Kniep <rapimo@adeven.com>)
List 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 by date:

Previous
From: Melvin Davidson
Date:
Subject: Re: Partitioning and ORM tools
Next
From: Manuel Kniep
Date:
Subject: Re: Partitioning and ORM tools