Re: Partitioning and ORM tools

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: 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:17:05
Message-ID: 56F1C461.5000107@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Manuel Kniep 2016-03-22 22:34:06 Re: Partitioning and ORM tools
Previous Message Melvin Davidson 2016-03-22 21:24:27 Re: Partitioning and ORM tools