Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 8 Sep 2004, Tom Lane wrote:
It wouldn't quite work to use just transaction ID as the marker, since
the inner SET CONSTRAINTS is very possibly done without using a
subtransaction. But command ID or query nesting level or some such
would work. I
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 8 Sep 2004, Tom Lane wrote:
Yeah, I had come to the same conclusion after more thought. But we
could certainly aggregate all the similar events generated by a single
query into a common status structure.
Definately. The ~20 byte/row gain for
I wrote:
Actually, I'd really like to get it back down to the 7.4 size, which was
already too big :-(. That might be a vain hope though.
As long as we're talking about hack-slash-and-burn on this data
structure ...
The cases where people get annoyed by the size of the deferred trigger
list
On Wed, 8 Sep 2004, Tom Lane wrote:
I wrote:
Actually, I'd really like to get it back down to the 7.4 size, which was
already too big :-(. That might be a vain hope though.
As long as we're talking about hack-slash-and-burn on this data
structure ...
The cases where people get annoyed
Stephan Szabo [EMAIL PROTECTED] writes:
Right, but if we search the entire trigger queue from the beginning
looking for all triggers now immediate and fire them in the EndQuery of
the set constraints statement contained in D, we'd potentially get an
ordering like:
Trigger A start
Trigger D
On Wed, 8 Sep 2004, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Right, but if we search the entire trigger queue from the beginning
looking for all triggers now immediate and fire them in the EndQuery of
the set constraints statement contained in D, we'd potentially get an
Stephan Szabo [EMAIL PROTECTED] writes:
Okay. The former seems odd to me, especially for exception handling since
Trigger D is making Trigger C immediate, but it could receive exceptions
for Trigger B, so it couldn't assume it knows the source of the exception
(C or something done due to C's
On Wed, 8 Sep 2004, Tom Lane wrote:
Hmm. Here's a slightly off the wall idea: following SET CONSTRAINTS,
scan the pending-triggers list twice. The first time, you determine
which triggers you need to fire, and mark them in progress by your
transaction. The second time through, you actually
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 8 Sep 2004, Tom Lane wrote:
I think the main concern here would be the space cost of
adding still another field to the trigger records ... is it worth it?
Would it be possible to basically alias the space for dte_done_xid to hold
either the xid
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 8 Sep 2004, Tom Lane wrote:
As long as we're talking about hack-slash-and-burn on this data
structure ...
Where the OtherInformation could be shared within the statement (for
identical events)? I think it'd be problematic to try sharing between
On Wed, 8 Sep 2004, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 8 Sep 2004, Tom Lane wrote:
As long as we're talking about hack-slash-and-burn on this data
structure ...
Where the OtherInformation could be shared within the statement (for
identical events)? I think
Stephan Szabo [EMAIL PROTECTED] writes:
Definately. The ~20 byte/row gain for large updates/insert/delete is
worth it. I think it'd actually increase the size for the single row case
since we'd have the pointer to deal with (we could use a flag that tells
us whether this item actually has a
Here's another thing that I think it would be good to fix in 8.0.
We've had numerous complaints before about RI constraints not firing
inside PL functions; a recent one is
http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php
I think also that the current behavior violates the SQL spec.
On Tue, 7 Sep 2004, Tom Lane wrote:
* EndQuery processes and discards immediate-mode AFTER trigger events for the
current query. Any remaining events (ie, DEFERRED triggers) are appended
to the current (sub)transaction's list of pending deferred triggers.
Note that even inside a
Stephan Szabo [EMAIL PROTECTED] writes:
If I'm reading the above correctly, I think DeferredTriggerSetState may
need to change a little if EndQuery works on a separate list of triggers
because I believe set constraints immediate currently depends on EndQuery
going over the entire list of saved
On Tue, 7 Sep 2004, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
If I'm reading the above correctly, I think DeferredTriggerSetState may
need to change a little if EndQuery works on a separate list of triggers
because I believe set constraints immediate currently depends on
Stephan Szabo [EMAIL PROTECTED] writes:
I misread then. I thought that you were proposing that EndQuery look only
at the per-query list and then add the deferred items that weren't fired
to the main list but never go over that list.
It will have to re-examine the tail of the main list, as
On Tue, 7 Sep 2004, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I misread then. I thought that you were proposing that EndQuery look only
at the per-query list and then add the deferred items that weren't fired
to the main list but never go over that list.
It will have to
Stephan Szabo [EMAIL PROTECTED] writes:
Hmm, if our current state of deferred triggers look like (in order)
Trigger A
Trigger B
Trigger C
and triggers A and B are made immediate and scanning begins at the
beginning of the queue again, during the execution of the Trigger A
trigger
On Tue, 7 Sep 2004, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Hmm, if our current state of deferred triggers look like (in order)
Trigger A
Trigger B
Trigger C
and triggers A and B are made immediate and scanning begins at the
beginning of the queue again, during
20 matches
Mail list logo
