> 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).
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.
In response to
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|