Mark Kirkwood <[EMAIL PROTECTED]> writes:
> A amendment so as not not require a SELECT from the main table in the
> trigger procedure. This makes the intent of the code more obvious, and
> makes more sense within the context of the example.
Yeah, much better. Applied.
reg
Mark Kirkwood wrote:
Looking at option 2, it seems reasonable to add a trimmed trigger
example into the plpgsql examples section now, and leave the data
warehouse introductory stuff for its own chapter at some later stage.
Sorry about this -
A amendment so as not not require a SELECT from the ma
Mark Kirkwood <[EMAIL PROTECTED]> writes:
> Looking at option 2, it seems reasonable to add a trimmed trigger
> example into the plpgsql examples section now, and leave the data
> warehouse introductory stuff for its own chapter at some later stage.
Patch applied.
regard
Mark Kirkwood wrote:
2) Perhaps leave the trigger + plpgsql function as a plpgsql example,
and refer to it in the (new) data warehouse section/chapter.
Looking at option 2, it seems reasonable to add a trimmed trigger
example into the plpgsql examples section now, and leave the data
warehouse
Bruce Momjian wrote:
Wow, yea, that is long. Not sure where that should go.
hmmm, yep - I could shorten it by removing :
- the COPY, ANALYZE (and maybe some of the INDEX) statements
- the queries and EXPLAINS at the end
However, this means that it is not clear what the point of the exercise
is
Wow, yea, that is long. Not sure where that should go.
---
Mark Kirkwood wrote:
> I have always thought that an example of how to maintain a summary table
> via triggers would be nice... but until the other day, had not at
I have always thought that an example of how to maintain a summary table
via triggers would be nice... but until the other day, had not attempted
to do one, so contributing a simplified version seemed like a good thing
to do.
I have made the example pretty much self contained, which unfortunate
