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 trig
On 3/31/09 9:45 AM, Emmanuel Cecchet wrote:
Yes, there is a good reason. As a trigger can update the tuple value,
this can change the routing decision. If you have a user trigger that
tries to change the key value after the partition choice has been made,
this will lead to an integrity constraint
Emmanuel Cecchet writes:
> Yes, there is a good reason. As a trigger can update the tuple value,
> this can change the routing decision. If you have a user trigger that
> tries to change the key value after the partition choice has been made,
> this will lead to an integrity constraint violatio
Yes, there is a good reason. As a trigger can update the tuple value,
this can change the routing decision. If you have a user trigger that
tries to change the key value after the partition choice has been made,
this will lead to an integrity constraint violation which is probably
not what the
Tom Lane wrote:
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
Alvaro Herrera writes:
> Nikhil Sontakke escribió:
>>> As triggers are executed in order of their names, we've prefixed the
>>> trigger names with "zz". This should work fine as long as no-one uses
>>> trigger-name which starts with "zz".
>> this seems a lot fragile...
> We already have system t
On Tue, Mar 31, 2009 at 9:46 AM, Alvaro Herrera
wrote:
>>
>> AFAICS, we do not have any category like system triggers. So yeah, it would
>> have been nice to generate triggers with names (starting with __ for
>> example) for such special triggers. But I don't think we disallow
>> user-triggers sta
Nikhil Sontakke escribió:
> > >> As triggers are executed in order of their names, we've prefixed the
> > >> trigger names with "zz". This should work fine as long as no-one uses
> > >> trigger-name which starts with "zz".
> >
> > this seems a lot fragile... why system generated triggers has to b
Hi,
>
> >> As triggers are executed in order of their names, we've prefixed the
> >> trigger names with "zz". This should work fine as long as no-one uses
> >> trigger-name which starts with "zz".
> >>
>
> this seems a lot fragile... why system generated triggers has to be
> executed following th
I agree with Jaime that system triggers should execute independently of
user triggers.
In the particular case of partitioning, the system trigger should
execute after the user triggers. However, as the partitioning trigger is
a row level trigger, it is not clear what is going to happen with user
On Mon, Mar 30, 2009 at 6:51 AM, Kedar Potdar wrote:
>
>> As triggers are executed in order of their names, we've prefixed the
>> trigger names with "zz". This should work fine as long as no-one uses
>> trigger-name which starts with "zz".
>>
this seems a lot fragile... why system generated trig
Hi Emmanuel,
Thanks for your time. This is a WIP patch and we will integrate your
suggestions/comments as appropriate.
Regards,
--
Kedar.
On Fri, Mar 27, 2009 at 3:38 AM, Emmanuel Cecchet wrote:
> Hi Kedar,
>
> First of all, congratulations for the excellent work.
> I have some comments and que
Hi Kedar,
First of all, congratulations for the excellent work.
I have some comments and questions.
In get_relevent_partition (btw, relevant is spelled with an a) you are
maintaining 2 lists. I guess this is only useful for multi-column
partitions, right?
If you have a single column partition
Hi Nikhil,
Update operation is performed as a combination of 'delete' and 'insert'.
In Update trigger, the row is deleted from relation according to it's
'ctid'. A look-up on system catalog for partitions is performed to identify
the target table by evaluating values of partition-key attributes,
Hi Kedar,
>
>
> The syntax used conforms to most of the suggestions mentioned in
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php, barring
> the following:
> -- Specification of partition names is optional. System will be able to
> generate partition names in such cases.
> -- Su
15 matches
Mail list logo
