Peter Eisentraut pete...@gmx.net writes:
Applied with some tweaks.
Thanks!
There's a typo I made that I see only now:
+ varlistentry
+ termstructfieldtg_event//term
I think that should be event, not tg_event, because we're listing
the fields for the EventTriggerData structure and
On Thu, 2013-07-04 at 10:15 +0200, Dimitri Fontaine wrote:
There's a typo I made that I see only now:
+ varlistentry
+ termstructfieldtg_event//term
Fixed.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Mon, 2013-05-06 at 17:17 +0200, Dimitri Fontaine wrote:
Please find attached a patch against the documentation, containing a
full code example of what I had in mind.
Applied with some tweaks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut pete...@gmx.net writes:
Random observation in this general area: Regular triggers provide the
field Trigger *tg_trigger in the trigger data, which allows you to get
the trigger name, OID, and such. Event triggers don't expose anything
comparable. That should perhaps be
Peter Eisentraut pete...@gmx.net writes:
Looks pretty good, but the description of the parsetree field was
obviously copied from somewhere else. I would fix it myself, but I
don't know what kind of assurances we want to offer about what's in that
field.
Oh, oops.
I think we should direct
Random observation in this general area: Regular triggers provide the
field Trigger *tg_trigger in the trigger data, which allows you to get
the trigger name, OID, and such. Event triggers don't expose anything
comparable. That should perhaps be added.
Also, as I'm maybe about the fourth
On Mon, 2013-05-06 at 17:17 +0200, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
At this point, all that is appropriate is some documentation of the C
API. If the contrib example you have in mind is short enough, it might
as well become part of the example in the
Peter Eisentraut pete...@gmx.net writes:
At this point, all that is appropriate is some documentation of the C
API. If the contrib example you have in mind is short enough, it might
as well become part of the example in the documentation.
Please find attached a patch against the
Peter Eisentraut pete...@gmx.net writes:
It seems pretty straightforward and useful, so I'm not sure where your
hesitation is coming from.
If you're talking about my hesitation to consider what we have now as
marketing material worthy, it comes from the fact that I don't have a
use case where I
On Thu, 2013-04-18 at 17:31 +0200, Dimitri Fontaine wrote:
- what about support for PLs other than C and PLpgSQL?
It used to be part of the patch, and I don't understand well
enough
the development calendar to guess if I'm supposed to extract that
from earlier patch or if
On Wed, Apr 17, 2013 at 3:20 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Please also note that the first series of patches did include the
support code for all the core PL, but Robert didn't feel like commiting
that and no other commiter did step up.
Of course, the chances of that would
On 4/18/13 11:31 AM, Dimitri Fontaine wrote:
The only questions in this thread are:
- only docs or docs + contrib example?
At this point, all that is appropriate is some documentation of the C
API. If the contrib example you have in mind is short enough, it might
as well become part of the
Peter Eisentraut pete...@gmx.net writes:
Offhand, that seems about enough, but I'm just beginning to explore.
I'm interested into hearing about any such use case…
Chances are, event triggers will end up somewhere near the top of the
release announcements, so we should have a consistent
Dimitri Fontaine escribió:
Peter Eisentraut pete...@gmx.net writes:
Offhand, that seems about enough, but I'm just beginning to explore.
I'm interested into hearing about any such use case…
Chances are, event triggers will end up somewhere near the top of the
release announcements, so
On 4/18/13 5:05 AM, Dimitri Fontaine wrote:
Peter Eisentraut pete...@gmx.net writes:
Offhand, that seems about enough, but I'm just beginning to explore.
I'm interested into hearing about any such use case…
Without going into too many details (because I don't have them yet), I
was thinking
Alvaro Herrera alvhe...@2ndquadrant.com writes:
You can be as much silent as you want in marketing materials (though
maybe Berkus will disagree with you about being silent there), but it is
not admissible to be silent in the documentation or pretend the feature
is not there. Whatever got
Peter Eisentraut pete...@gmx.net writes:
Without going into too many details (because I don't have them yet), I
was thinking about triggering an external test suite whenever there is a
schema change in the database.
So if all you want to know about is that something did change in the
schema to
Dimitri Fontaine escribió:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
You can be as much silent as you want in marketing materials (though
maybe Berkus will disagree with you about being silent there), but it is
not admissible to be silent in the documentation or pretend the feature
Peter Eisentraut pete...@gmx.net writes:
I'm specifically looking for C API documentation, along the lines of
http://www.postgresql.org/docs/devel/static/trigger-interface.html.
The current chapter on event triggers might as well be ripped out and
folded into the CREATE EVENT TRIGGER
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
I'm not sure about ripping it out, it does not sound like a good idea to
me. It needs some addition and C level examples yes. The plan was to
build a contrib module as an example, that would cancel any (supported)
command you try to run by means
On 4/17/13 5:41 AM, Dimitri Fontaine wrote:
I'm not sure about ripping it out, it does not sound like a good idea to
me. It needs some addition and C level examples yes. The plan was to
build a contrib module as an example, that would cancel any (supported)
command you try to run by means of
Peter Eisentraut pete...@gmx.net writes:
Well, if documentation had been available well before beta, other
procedural languages might have gained support for event triggers. If
it's not being documented, it might not happen very soon.
It's been a moving target for the last two years, and
On 4/17/13 3:20 PM, Dimitri Fontaine wrote:
It would have been good to have at least one untrusted language with
event trigger support, so that you can hook in external auditing or
logging systems. With the existing PL/pgSQL support, the possible
actions are a bit limited.
Well, you do
On Mon, Apr 15, 2013 at 11:57 PM, Peter Eisentraut pete...@gmx.net wrote:
I'm having trouble finding documentation about how to write event
triggers. The chapter in the documentation
http://www.postgresql.org/docs/devel/static/event-triggers.html
says they can be written in C or supported
On 4/16/13 7:49 AM, Robert Haas wrote:
On Mon, Apr 15, 2013 at 11:57 PM, Peter Eisentraut pete...@gmx.net wrote:
I'm having trouble finding documentation about how to write event
triggers. The chapter in the documentation
http://www.postgresql.org/docs/devel/static/event-triggers.html
says
I'm having trouble finding documentation about how to write event
triggers. The chapter in the documentation
http://www.postgresql.org/docs/devel/static/event-triggers.html
says they can be written in C or supported PLs, but does not explain it
any further. Is there any documentation for it?
26 matches
Mail list logo
