On 10 October 2010 19:06, Tom Lane t...@sss.pgh.pa.us wrote:
Applied with revisions.
Brilliant! Thank you very much.
* I took out this change in planmain.c:
+ /*
+ * If the query target is a VIEW, it won't be in the jointree, but we
+ * need a dummy RelOptInfo node for
Bernd Helmle maili...@oopsware.de writes:
--On 8. September 2010 09:00:33 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
Here's an updated version with improved formatting and a few minor
wording changes to the triggers chapter.
This version doesn't apply clean anymore due to some
Bernd Helmle maili...@oopsware.de writes:
I would like to do some more tests/review, but going to mark this patch as
Ready for Committer, so that someone more qualified on the executor part
can have a look on it during this commitfest, if that's okay for us?
I've started looking at this
On 8 October 2010 16:50, Tom Lane t...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
I would like to do some more tests/review, but going to mark this patch as
Ready for Committer, so that someone more qualified on the executor part
can have a look on it during this
Dean Rasheed dean.a.rash...@gmail.com writes:
On 8 October 2010 16:50, Tom Lane t...@sss.pgh.pa.us wrote:
I've started looking at this patch now. I think it would have been best
submitted as two patches: one to add the SQL-spec INSTEAD OF trigger
functionality, and a follow-on to extend
On Fri, Oct 8, 2010 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I think the
right thing here is to replace before with a three-valued enum,
perhaps called timing, so as to force people to take another look
at any code that touches the field directly.
+1. That seems much nicer.
Although
Robert Haas robertmh...@gmail.com writes:
On Fri, Oct 8, 2010 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Although we already have macros TRIGGER_FIRED_AFTER/TRIGGER_FIRED_BEFORE
that seem to mask the details here, the changes you had to make in
contrib illustrate that the macros' callers
BTW, while I'm looking at this: it seems like the index arrays in
struct TrigDesc are really a lot more complication than they are worth.
It'd be far easier to dispense with them and instead iterate through
the main trigger array, skipping any triggers whose tgtype doesn't match
what we need. If
On 5 October 2010 21:17, Bernd Helmle maili...@oopsware.de wrote:
Basic summary of this patch:
Thanks for the review.
* The patch includes a fairly complete discussion about INSTEAD OF triggers
and their usage on views. There are also additional enhancements to the RULE
documentation, which
--On 30. September 2010 07:38:18 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
This version doesn't apply clean anymore due to some rejects in
plainmain.c. Corrected version attached.
Ah yes, those pesky bits have been rotting while I wasn't looking.
Thanks for fixing them!
Basic
On 29 September 2010 20:18, Bernd Helmle maili...@oopsware.de wrote:
--On 8. September 2010 09:00:33 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
Here's an updated version with improved formatting and a few minor
wording changes to the triggers chapter.
This version doesn't apply
On 23 September 2010 00:26, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-09-23 1:16 AM, Bernd Helmle wrote:
INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
text | id
+
helmle | 2
(1 row)
SELECT * FROM vfoo;
text | id
---+
bernd | 2
(1 row)
--On 23. September 2010 08:59:32 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
Yes, I agree. To me this is the least surprising behaviour. I think a
more common case would be where the trigger computed a value (such as
the 'last updated' example). The executor doesn't have any kind of
--On 5. September 2010 09:09:55 +0100 Dean Rasheed
dean.a.rash...@gmail.com wrote:
I had a first look on your patch, great work!
Attached is an updated patch with more tests and docs, and a few minor
code tidy ups. I think that the INSTEAD OF triggers part of the patch
is compliant with
On 2010-09-23 1:16 AM, Bernd Helmle wrote:
INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
text | id
+
helmle | 2
(1 row)
SELECT * FROM vfoo;
text | id
---+
bernd | 2
(1 row)
This is solvable by a properly designed trigger function, but maybe we need
to do
On 7 September 2010 02:03, David Christensen da...@endpoint.com wrote:
On Sep 5, 2010, at 3:09 AM, Dean Rasheed wrote:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
Here is a WIP patch implementing triggers on VIEWs ... snip
There are still a number of things left
On Sep 5, 2010, at 3:09 AM, Dean Rasheed wrote:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
Here is a WIP patch implementing triggers on VIEWs ... snip
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
- much
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further reflection, I wonder if the ability to disable VIEW
triggers is needed/wanted at all. I just noticed that
Dean Rasheed dean.a.rash...@gmail.com writes:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further reflection, I wonder if the ability to disable VIEW
triggers
On 16 August 2010 18:50, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
On 15 August 2010 18:38, Dean Rasheed dean.a.rash...@gmail.com wrote:
There are still a number of things left todo:
- extend ALTER VIEW with enable/disable trigger commands
On further
20 matches
Mail list logo
