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
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 |