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 the same rules
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 be
executed
On Tue, Mar 31, 2009 at 9:46 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
Alvaro Herrera alvhe...@commandprompt.com 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
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
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
Emmanuel Cecchet m...@asterdata.com 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
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
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
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 m...@asterdata.comwrote:
Hi Kedar,
First of all, congratulations for the excellent work.
I have some
On Mon, Mar 30, 2009 at 6:51 AM, Kedar Potdar kedar.pot...@gmail.com 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
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
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.
-- Sub
15 matches
Mail list logo
