Hi,

> We already have system triggers -- the FK triggers.  I don't think we've
>>> had all that much trouble with them.
>>>
>>>
>>
>> In the case of the FK triggers, it's intentional (and maybe even
>> documented) that users should be able to place their own triggers before
>> or after the FK triggers.
>>
>
> If it's documented I think it's well hidden ;-) ISTM that the fact that we
> implement FK constraints via triggers is really an implementation detail,
> not something the user should be encouraged to mess with.
>
>   Is there a good reason why partitioning
>> triggers should be different?
>>
>
> Probably not. ISTM that the scheme should turn tgisconstraint into a
> multi-valued item (tgkind: 'u' = userland, 'c'= constraint, 'p' = partition
> or some such).
>

+1.

This seems to be the best way forward if we stick to triggers for
partitioning. I think they appear to serve the purpose well for this
use-case and maybe with this scheme they will be low-level enough too.

Regards,
Nikhils
-- 
http://www.enterprisedb.com

In response to

• Re: Partitioning feature ... at 2009-03-31 15:59:45 from Andrew Dunstan

pgsql-hackers by date

Next:	From: Hitoshi Harada	Date: 2009-04-01 10:13:40
	Subject: Re: Sort a column that does not exist
Previous:	From: Vlad Arkhipov	Date: 2009-04-01 03:52:03
	Subject: Duplicate key value error