Re: [HACKERS] Command Triggers, v16
On Sun, Mar 25, 2012 at 12:15 PM, Andres Freund and...@2ndquadrant.com wrote: On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote: This will have the effect of calling triggers outside of alphabetic order. I don't think thats a good idea even if one part is ANY and the other a specific command. I don't think there is any reason anymore to separate the two? The only callsite seems to look like: The idea is to have a predictable ordering of command triggers. The code changed in the patch v16 (you pasted code from git in between v15 and v16, I cleaned it up) and is now easier to read: case CMD_TRIGGER_FIRED_BEFORE: whenstr = BEFORE; procs[0] = cmd-before_any; procs[1] = cmd-before; break; case CMD_TRIGGER_FIRED_AFTER: whenstr = AFTER; procs[0] = cmd-after; procs[1] = cmd-after_any; break; So it's BEFORE ANY then BEFORE command then AFTER command then AFTER ANY. That's an arbitrary I made and we can easily reconsider. Triggers are called in alphabetical order in each “slot” here. In my mind it makes sense to have ANY triggers around the specific triggers, but it's hard to explain why that feels better. I still think this would be a mistake. I don't have a hard time imagining usecases where a specific trigger should be called before or after an ANY trigger because e.g. it wants to return a more specific error or doesn't want to check all preconditions already done by the ANY trigger... All that would be precluded by enforcing a strict ordering between ANY and specific triggers. I don't see a use-case that would benefit from the current behaviour... Dimitri's proposed behavior would be advantageous if you have an ANY trigger that wants to take over the world and make sure that nobody else can run before it. I think, though, that's not a case we want to cater to - all of this stuff requires superuser privileges anyway, so we should assume that the DBA knows what he's doing. So +1 for making it strictly alphabetical, as we do with other triggers. Everything that can be done under Dimitri's proposal can also be done in that scheme, but the reverse is not true. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Robert Haas robertmh...@gmail.com writes: Dimitri's proposed behavior would be advantageous if you have an ANY trigger that wants to take over the world and make sure that nobody else can run before it. I think, though, that's not a case we want to cater to - all of this stuff requires superuser privileges anyway, so we should assume that the DBA knows what he's doing. So +1 for making What about extensions? One use case would be for londiste/slony/bucardo to rewrite the command and queue its text, that will be done in C and should probably be done first. Using an ANY command trigger means that code will run before user specific code (or likewise after it). As I said it's not that clear in my head, but when thinking about command trigger and extensions, it could be better to impose an arbitrary order here. it strictly alphabetical, as we do with other triggers. Everything that can be done under Dimitri's proposal can also be done in that scheme, but the reverse is not true. That's true too. I'm just not sure how much it applies to code installed by the DBA as opposed to written by the DBA. I'll be happy to edit the patch to melt both lists if that's the decision, it's not hard to do so. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Can someone clarify whether this will be reviewed by a committer? Will there be time to get this reviewed before the commitfest closes? I get the impression the commitfest closure is fairly imminent. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Mon, Mar 26, 2012 at 3:24 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: One use case would be for londiste/slony/bucardo to rewrite the command and queue its text, that will be done in C and should probably be done first. Using an ANY command trigger means that code will run before user specific code (or likewise after it). And, if the user wants it to be run first, he or she can do that. But suppose he wants to run it first, and also forbid users whose username starts with the letter b from running the ANALYZE command. Well, then, he now wants that trigger to come before the other one, even though the Slony trigger is for all commands (maybe) and the other just for ANALYZE (maybe). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Robert Haas robertmh...@gmail.com writes: Dimitri's proposed behavior would be advantageous if you have an ANY trigger that wants to take over the world and make sure that nobody else can run before it. I think, though, that's not a case we want to cater to - all of this stuff requires superuser privileges anyway, so we should assume that the DBA knows what he's doing. So +1 for making What about extensions? One use case would be for londiste/slony/bucardo to rewrite the command and queue its text, that will be done in C and should probably be done first. Using an ANY command trigger means that code will run before user specific code (or likewise after it). Unless you intend a restriction that there be only one ANY trigger, I don't see how that follows. AFAICS, the only way to guarantee my trigger runs first is to give it a name alphabetically before anything else in the system. Also, it strikes me that in most of the trigger ordering cases I've seen, it's actually more interesting to want to be sure that a particular trigger runs *last* so that its effects can't be modified by some other, hypothetically less trusted, trigger. So I don't think that the mere fact of being an ANY trigger rather than a command-specific trigger should be taken to mean that a particular ordering is desirable. Trigger name order isn't the greatest solution by any means, but it's more flexible than hard-wiring according to trigger type. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Thom Brown thombr...@gmail.com writes: Can someone clarify whether this will be reviewed by a committer? Will there be time to get this reviewed before the commitfest closes? I get the impression the commitfest closure is fairly imminent. I don't have that impression. (I wish I did.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Mon, Mar 26, 2012 at 3:36 PM, Thom Brown thombr...@gmail.com wrote: Can someone clarify whether this will be reviewed by a committer? Will there be time to get this reviewed before the commitfest closes? I get the impression the commitfest closure is fairly imminent. Well, I have been holding off for two reasons: 1. It sure seems like there is an awful lot of code churn and design work going on. 2. I'm not sure which patches Tom is planning to look at or in what order, so I've been avoiding the ones he seems to be taking an interest in. Personally, I am about at the point where I'd like to punt everything and move on. As nice as it would be to squeeze a few more things into 9.2, there WILL be a 9.3. If a few less people had submitted half-baked code at the last minute and a few more people had helped with review, we'd be done by now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Tom Lane t...@sss.pgh.pa.us writes: So I don't think that the mere fact of being an ANY trigger rather than a command-specific trigger should be taken to mean that a particular ordering is desirable. Trigger name order isn't the greatest solution by any means, but it's more flexible than hard-wiring according to trigger type. That ANY sandwich idea is then dead, I will fix it tomorrow to rather just handle a single list of BEFORE and AFTER triggers (that's 2 lists total) ordered by trigger name. v19 will also integrate latest doc comments from Thom and most from Andres, I don't know how to fix the plpython specifics he's talking about. About the reviewing and the commit fest closing, even if that patch is big it's a principled implementation: the integration of the facility is done in the same way in lots of different places, and is not rocket science either (we removed all the complexity). So I guess it's not really an herculean job here, just a certain amount of mechanical edits: we just support too many commands ;) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Monday, March 26, 2012 10:18:59 PM Dimitri Fontaine wrote: don't know how to fix the plpython specifics he's talking about. Just copy what is done in the normal trigger handling facility (the decref both in the CATCH and in the normal path). Ping me some other way if you need help... Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Robert Haas robertmh...@gmail.com writes: 1. It sure seems like there is an awful lot of code churn and design work going on. There has only been minor adjustments for a while now, and they have been visible because Thom was doing lots of testing for me and it was way easier for me to publish a new version and have a test result the next day (thanks again Thom). Personally, I am about at the point where I'd like to punt everything and move on. As nice as it would be to squeeze a few more things into 9.2, there WILL be a 9.3. If a few less people had submitted half-baked code at the last minute and a few more people had helped with review, we'd be done by now. Well, wait a minute. There's a difference between half-baked and reacting to a review that changes the goal of a patch. My idea of the code I wanted to write here is extremely different from what we as a community decided to be doing. The main part of the code churn has been answering to review, removing features and cleaning the code afterwards. The only major design decision that I had to change here has been about from where to call in the command trigger code in the existing commands implementation, and it was done before entering this CF, IIRC. If you want to punt this patch out of 9.2 after all the changes I had to make for it to be a candidate for 9.2, I think it would be only fair for you to find a show stopper in my current implementation. The trigger firing order is about an hour of work, so not a stopper I believe. And as soon as we're done here, you know I'll put the same hours and energy into reviewing other people patches :) Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 26 March 2012 21:36, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Robert Haas robertmh...@gmail.com writes: Personally, I am about at the point where I'd like to punt everything and move on. As nice as it would be to squeeze a few more things into 9.2, there WILL be a 9.3. If a few less people had submitted half-baked code at the last minute and a few more people had helped with review, we'd be done by now. Well, wait a minute. There's a difference between half-baked and reacting to a review that changes the goal of a patch. My idea of the I think Robert was referring to patches in general. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Mon, Mar 26, 2012 at 4:36 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Well, wait a minute. There's a difference between half-baked and reacting to a review that changes the goal of a patch. My idea of the code I wanted to write here is extremely different from what we as a community decided to be doing. The main part of the code churn has been answering to review, removing features and cleaning the code afterwards. Sure. And if this weren't the final CommitFest, we would have bumped this to the next CommitFest two months ago. Since it is the final CommitFest, we're going to go on and on and on. Already we have almost as many patches queued up for the next CommitFest as we do remaining in this one. So my question is: how long should we keep all those people waiting for the purpose of squeezing more stuff into 9.2? At the beginning of this CommitFest, various people offered time frames ranging between 6 weeks to 2 months. We're past that now. If you don't think that was a long enough time frame, then how long do you think we should wait? It doesn't seem to me to matter very much whether this got stretched out due to fundamental design deficiencies or just because it takes a while to beat a major feature into committable form; surely it's not a shock that this patch wasn't going to go in overnight. If you want to punt this patch out of 9.2 after all the changes I had to make for it to be a candidate for 9.2, I think it would be only fair for you to find a show stopper in my current implementation. The trigger firing order is about an hour of work, so not a stopper I believe. I don't think there is a show-stopper. I do think there is probably a lot more cleaning up, tidying, and adjusting needed. And as soon as we're done here, you know I'll put the same hours and energy into reviewing other people patches :) As soon as we're done here, the CommitFest will end, and there won't be any other people's patches to review. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Mon, Mar 26, 2012 at 4:45 PM, Robert Haas robertmh...@gmail.com wrote: As soon as we're done here, the CommitFest will end, and there won't be any other people's patches to review. Hurray? :-) -- When confronted by a difficult problem, solve it by reducing it to the question, How would the Lone Ranger handle this? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Robert Haas robertmh...@gmail.com writes: 2. I'm not sure which patches Tom is planning to look at or in what order, so I've been avoiding the ones he seems to be taking an interest in. Well, I think I'm definitely on the hook for the pg_stat_statements, pgsql_fdw, foreign table stats, and caching-stable-subexpressions patches, and I should look at the libpq alternate row returning mechanism because I suspect I was the last one to mess with that libpq code in any detail. I don't claim any special insight into the other stuff on the list. In particular I've not been paying much attention to command triggers. Personally, I am about at the point where I'd like to punt everything and move on. As nice as it would be to squeeze a few more things into 9.2, there WILL be a 9.3. If a few less people had submitted half-baked code at the last minute and a few more people had helped with review, we'd be done by now. The main reason I proposed setting a schedule a few weeks ago was that I was afraid the commitfest would otherwise end precisely in a we're tired out, we're punting everything to 9.3 moment. Without some definite goal to work towards, it'll just keep stretching out until we've had enough. I'd prefer it end in a more orderly fashion than that. The end result will be the same, in the sense that some of the stuff that's still-not-ready-for-committer is going to get punted, but people might have a less bad taste in their mouths about why. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Mar 26, 2012, at 5:36 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: 2. I'm not sure which patches Tom is planning to look at or in what order, so I've been avoiding the ones he seems to be taking an interest in. Well, I think I'm definitely on the hook for the pg_stat_statements, pgsql_fdw, foreign table stats, and caching-stable-subexpressions patches, and I should look at the libpq alternate row returning mechanism because I suspect I was the last one to mess with that libpq code in any detail. I don't claim any special insight into the other stuff on the list. In particular I've not been paying much attention to command triggers. How long will that all take? I guess I'll work on command triggers, pg_archivecleanup, and buffer I/O timings next. Personally, I am about at the point where I'd like to punt everything and move on. As nice as it would be to squeeze a few more things into 9.2, there WILL be a 9.3. If a few less people had submitted half-baked code at the last minute and a few more people had helped with review, we'd be done by now. The main reason I proposed setting a schedule a few weeks ago was that I was afraid the commitfest would otherwise end precisely in a we're tired out, we're punting everything to 9.3 moment. Without some definite goal to work towards, it'll just keep stretching out until we've had enough. I'd prefer it end in a more orderly fashion than that. The end result will be the same, in the sense that some of the stuff that's still-not-ready-for-committer is going to get punted, but people might have a less bad taste in their mouths about why. Fine. What do you propose, specifically? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Friday, March 16, 2012 10:40:46 AM Dimitri Fontaine wrote: This will have the effect of calling triggers outside of alphabetic order. I don't think thats a good idea even if one part is ANY and the other a specific command. I don't think there is any reason anymore to separate the two? The only callsite seems to look like: The idea is to have a predictable ordering of command triggers. The code changed in the patch v16 (you pasted code from git in between v15 and v16, I cleaned it up) and is now easier to read: case CMD_TRIGGER_FIRED_BEFORE: whenstr = BEFORE; procs[0] = cmd-before_any; procs[1] = cmd-before; break; case CMD_TRIGGER_FIRED_AFTER: whenstr = AFTER; procs[0] = cmd-after; procs[1] = cmd-after_any; break; So it's BEFORE ANY then BEFORE command then AFTER command then AFTER ANY. That's an arbitrary I made and we can easily reconsider. Triggers are called in alphabetical order in each “slot” here. In my mind it makes sense to have ANY triggers around the specific triggers, but it's hard to explain why that feels better. I still think this would be a mistake. I don't have a hard time imagining usecases where a specific trigger should be called before or after an ANY trigger because e.g. it wants to return a more specific error or doesn't want to check all preconditions already done by the ANY trigger... All that would be precluded by enforcing a strict ordering between ANY and specific triggers. I don't see a use-case that would benefit from the current behaviour... Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote: On 15 March 2012 22:06, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Dimitri Fontaine dimi...@2ndquadrant.fr writes: At this moment in time, CTAS is still outstanding. Is the plan to try to get that in for this release, or as an enhancement in 9.3? The plan is to get CTAS as a utility command in 9.2 then update the command trigger patch to benefit from the new situation. We've been wondering about making its own commit fest entry for that patch, it's now clear in my mind, that needs to happen. https://commitfest.postgresql.org/action/patch_view?id=823 Looks like the ctas-on-command-triggers-01.patch patch needs re-basing. I can do that - but imo the other patch (not based on the command triggers stuff) is the relevant for now as this patch ought to be applied before command triggers. It doesn't seem to make too much sense to rebase it frequently as long as the command triggers patch isn't stable... Any reason you would prefer it being rebased? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
* Thom Brown wrote: I don’t understand how functions can return a type of “command trigger”. This certainly works, but I’ve never seen a type consisting of more than one word. Could you explain this for me? This is also postgres= with types (name) as postgres- (select format_type(oid, NULL) from pg_type) postgres- select name from types where name like '% %' postgres- and not name like '%[]'; name - double precision character varying time without time zone timestamp without time zone timestamp with time zone time with time zone bit varying (7 Zeilen) I think these are all specially handled in the parser. -- Christian Ullrich -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 16 March 2012 08:13, Andres Freund and...@anarazel.de wrote: On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote: Looks like the ctas-on-command-triggers-01.patch patch needs re-basing. I can do that - but imo the other patch (not based on the command triggers stuff) is the relevant for now as this patch ought to be applied before command triggers. It doesn't seem to make too much sense to rebase it frequently as long as the command triggers patch isn't stable... Any reason you would prefer it being rebased? Using latest Git master without any additional patches, I can't get it to apply: Hunk #1 FAILED at 16. Hunk #2 succeeded at 22 (offset -1 lines). 1 out of 2 hunks FAILED -- saving rejects to file src/include/commands/tablecmds.h.rej Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Hi,
On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote:
I tricked that in the grammar, the type is called cmdtrigger but I
though it wouldn't be a good choice for the SQL statement.
Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am
squeamish.
+ oid | typname | oid | proname
+--++--+
+ 1790 | refcursor | 46 | textin
+ 3838 | cmdtrigger | 2300 | trigger_in
+(2 rows)
Hm. Wonder if its a good idea to reuse trigger_in. So far we have duplicated
functions for that.
@@ -482,12 +494,21 @@ ListCommandTriggers(CommandContext cmd)
switch (form-ctgtype)
{
case CMD_TRIGGER_FIRED_BEFORE:
- cmd-before = lappend_oid(cmd-before, form-ctgfoid);
+ {
+ if (list_any_triggers)
+ cmd-before_any = lappend_oid(cmd-before_any,
form-ctgfoid); + else
+ cmd-before = lappend_oid(cmd-before, form-ctgfoid);
break;
-
...
+ case CMD_TRIGGER_FIRED_BEFORE:
+ {
+ whenstr = BEFORE;
+
+ foreach(cell, cmd-before_any)
+ {
+ Oid proc = lfirst_oid(cell);
+
+ call_cmdtrigger_procedure(cmd, (RegProcedure)proc,
whenstr); + }
+ foreach(cell, cmd-before)
+ {
+ Oid proc = lfirst_oid(cell);
+
+ call_cmdtrigger_procedure(cmd, (RegProcedure)proc,
whenstr); + }
+ break;
+ }
This will have the effect of calling triggers outside of alphabetic order. I
don't think thats a good idea even if one part is ANY and the other a specific
command.
I don't think there is any reason anymore to separate the two? The only
callsite seems to look like:
632-default:
633:ListCommandTriggers(cmd, true); /* list ANY command
triggers */
634:ListCommandTriggers(cmd, false); /* and triggers for
this
command tag */
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote: On 16 March 2012 08:13, Andres Freund and...@anarazel.de wrote: On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote: Looks like the ctas-on-command-triggers-01.patch patch needs re-basing. I can do that - but imo the other patch (not based on the command triggers stuff) is the relevant for now as this patch ought to be applied before command triggers. It doesn't seem to make too much sense to rebase it frequently as long as the command triggers patch isn't stable... Any reason you would prefer it being rebased? Using latest Git master without any additional patches, I can't get it to apply: Hunk #1 FAILED at 16. Hunk #2 succeeded at 22 (offset -1 lines). 1 out of 2 hunks FAILED -- saving rejects to file src/include/commands/tablecmds.h.rej Did you read the paragraph above? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 15 March 2012 21:58, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Thom Brown thombr...@gmail.com writes: I don’t understand how functions can return a type of “command trigger”. This certainly works, but I’ve never seen a type consisting of more than one word. Could you explain this for me? This is also I tricked that in the grammar, the type is called cmdtrigger but I though it wouldn't be a good choice for the SQL statement. Christian sent me a message mentioning that we've pretty much always had data types consisting of more than one word (e.g. timestamp without time zone). So I completely retract my question as it's obviously nonsense. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 16 March 2012 08:45, Andres Freund and...@anarazel.de wrote: On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote: On 16 March 2012 08:13, Andres Freund and...@anarazel.de wrote: On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote: Looks like the ctas-on-command-triggers-01.patch patch needs re-basing. I can do that - but imo the other patch (not based on the command triggers stuff) is the relevant for now as this patch ought to be applied before command triggers. It doesn't seem to make too much sense to rebase it frequently as long as the command triggers patch isn't stable... Any reason you would prefer it being rebased? Using latest Git master without any additional patches, I can't get it to apply: Hunk #1 FAILED at 16. Hunk #2 succeeded at 22 (offset -1 lines). 1 out of 2 hunks FAILED -- saving rejects to file src/include/commands/tablecmds.h.rej Did you read the paragraph above? Yes, but I don't think I'm clear on what you mean. Are you saying I should use ctas-01.patch instead of ctas-on-command-triggers-01.patch? If so, that patch results in me not being able to apply Dimitri's command triggers patch. And I thought that patch doesn't actually cause triggers to fire on CTAS? Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Friday, March 16, 2012 09:55:10 AM Thom Brown wrote: On 16 March 2012 08:45, Andres Freund and...@anarazel.de wrote: On Friday, March 16, 2012 09:30:58 AM Thom Brown wrote: On 16 March 2012 08:13, Andres Freund and...@anarazel.de wrote: On Thursday, March 15, 2012 11:41:21 PM Thom Brown wrote: Looks like the ctas-on-command-triggers-01.patch patch needs re-basing. I can do that - but imo the other patch (not based on the command triggers stuff) is the relevant for now as this patch ought to be applied before command triggers. It doesn't seem to make too much sense to rebase it frequently as long as the command triggers patch isn't stable... Any reason you would prefer it being rebased? Using latest Git master without any additional patches, I can't get it to apply: Hunk #1 FAILED at 16. Hunk #2 succeeded at 22 (offset -1 lines). 1 out of 2 hunks FAILED -- saving rejects to file src/include/commands/tablecmds.h.rej Did you read the paragraph above? Yes, but I don't think I'm clear on what you mean. Are you saying I should use ctas-01.patch instead of ctas-on-command-triggers-01.patch? If so, that patch results in me not being able to apply Dimitri's command triggers patch. And I thought that patch doesn't actually cause triggers to fire on CTAS? Well. Why do you want to apply them concurrently? As far as I understand the plan is to get ctas-as-utility merged with master and then let dim rebase the ddl trigger patch. The ctas-as-utility stuff imo is worthy of being applied independently of DDL triggers. The current duplication in the code lead to multiple bugs already. Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Andres Freund and...@anarazel.de writes: On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote: I tricked that in the grammar, the type is called cmdtrigger but I though it wouldn't be a good choice for the SQL statement. Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am squeamish. It's easy to remove that hack and get back to having the user visible type be cmdtrigger, but as this type only serves as a marker for PL compiling function (validate handler) I though having a user friendly name was important here. + oid | typname | oid | proname +--++--+ + 1790 | refcursor | 46 | textin + 3838 | cmdtrigger | 2300 | trigger_in +(2 rows) Hm. Wonder if its a good idea to reuse trigger_in. So far we have duplicated functions for that. Again, if we think the use case warrants duplicating code rather than playing with the type definition, I will do that. This will have the effect of calling triggers outside of alphabetic order. I don't think thats a good idea even if one part is ANY and the other a specific command. I don't think there is any reason anymore to separate the two? The only callsite seems to look like: The idea is to have a predictable ordering of command triggers. The code changed in the patch v16 (you pasted code from git in between v15 and v16, I cleaned it up) and is now easier to read: case CMD_TRIGGER_FIRED_BEFORE: whenstr = BEFORE; procs[0] = cmd-before_any; procs[1] = cmd-before; break; case CMD_TRIGGER_FIRED_AFTER: whenstr = AFTER; procs[0] = cmd-after; procs[1] = cmd-after_any; break; So it's BEFORE ANY then BEFORE command then AFTER command then AFTER ANY. That's an arbitrary I made and we can easily reconsider. Triggers are called in alphabetical order in each “slot” here. In my mind it makes sense to have ANY triggers around the specific triggers, but it's hard to explain why that feels better. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Thom Brown thombr...@gmail.com writes:
Note: incremental patch attached for the following section...
Applied, thanks!
I don’t know if this was a problem before that I didn’t spot
(probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE
show a command tag of ALTER TABLE for ALTER FOREIGN TABLE statements
where the column is renamed:
I don’t think this is the fault of the trigger code because it
actually says ALTER TABLE at the bottom, suggesting it’s something
already present. This isn’t the case when adding or dropping columns.
Any comments?
We're building command trigger on top of the existing code. From the
grammar we can see that an alter table and an alter foreign table are
processed as the same command.
AlterForeignTableStmt:
ALTER FOREIGN TABLE relation_expr alter_table_cmds
{
AlterTableStmt *n = makeNode(AlterTableStmt);
So while I think we could want to revisit that choice down the road, I
don't think that's for the command triggers patch to do it.
Altering the properties of a function (such as cost, security definer,
whether it’s stable etc) doesn’t report the function’s OID:
That's now fixed. I've checked that all the other places where we're
saying objectId = InvalidOid are related to before create or after drop
commands.
I get a garbage objectname for AFTER ANY COMMAND triggers on ALTER
TEXT SEARCH DICTIONARY when changing its options. It doesn’t show it
in the below example because I can’t get it displaying in plain text,
but where the objectname is blank is where I’m seeing unicode a square
containing “0074” 63 times in a row:
I couldn't reproduce, but I've spotted the problem in the source, and
fixed it. I could find a couple other places that should have been using
pstrdup(NameStr(…)) too, and fixed them. I added a test.
Specific command triggers on ALTER VIEW don’t work at all:
Can't reproduce, and that's already part of the regression tests.
Command triggers that fire for CREATE RULE show a schema, but DROP
RULE doesn’t. Which is it?:
Oh, both RULE and TRIGGER are not qualified, and I was filling the
schemaname with the schema of the relation they refer to in the CREATE
command, and had DROP correctly handling the TRIGGER case.
That's now fixed, schemaname is NULL in all cases here.
You can read the changes here:
https://github.com/dimitri/postgres/compare/5e8e37922d...144d870162
And I've been attaching an incremental patch too. Next patch revision is
expected later today with support for plpython, plperl and pltcl.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index f5f2079..5f84751 100644
--- a/doc/src/sgml/plpgsql.sgml
+++ b/doc/src/sgml/plpgsql.sgml
@@ -3933,20 +3933,19 @@ SELECT * FROM sales_summary_bytime;
titleTriggers on commands/title
para
-applicationPL/pgSQL/application can be used to define trigger
-procedures. A trigger procedure is created with the
+applicationPL/pgSQL/application can be used to define command
+trigger procedures. A command trigger procedure is created with the
commandCREATE FUNCTION/ command, declaring it as a function with
no arguments and a return type of typecommand trigger/type.
/para
para
When a applicationPL/pgSQL/application function is called as a
- trigger, several special variables are created automatically in the
- top-level block. They are:
+ command trigger, several special variables are created automatically
+ in the top-level block. They are:
variablelist
varlistentry
-varlistentry
termvarnameTG_TAG/varname/term
listitem
para
@@ -4002,7 +4001,7 @@ SELECT * FROM sales_summary_bytime;
/para
para
- The command trigger function return's value is not used.
+ The command trigger function's return value is not used.
/para
para
@@ -4014,23 +4013,20 @@ SELECT * FROM sales_summary_bytime;
titleA applicationPL/pgSQL/application Command Trigger Procedure/title
para
- This example trigger just raise a literalNOTICE/literal message
+ This example trigger simply raises a literalNOTICE/literal message
each time a supported command is executed.
/para
programlisting
-create or replace function snitch()
- returns command trigger
- language plpgsql
-as $$
-begin
- raise notice 'snitch: % % %.% [%]',
+CREATE OR REPLACE FUNCTION snitch() RETURNS command trigger AS $$
+BEGIN
+RAISE NOTICE 'snitch: % % %.% [%]',
tg_when, tg_tag, tg_schemaname, tg_objectname, tg_objectid;
-end;
-$$;
+END;
+$$ LANGUAGE plpgsql;
-create command trigger snitch_before before any command execute procedure any_snitch();
-create command trigger snitch_after after any command execute procedure any_snitch();
+CREATE COMMAND TRIGGER snitch_before BEFORE ANY COMMAND EXECUTE PROCEDURE snitch();
+CREATE COMMAND
Re: [HACKERS] Command Triggers, v16
On 16 March 2012 11:42, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Thom Brown thombr...@gmail.com writes: Specific command triggers on ALTER VIEW don’t work at all: Can't reproduce, and that's already part of the regression tests. This was a problem my side (a mistake I made previously) as I hadn't added this particular one into my list of created command triggers. I had then seen the triggers fire, but forgot to go back and remove my statement from the draft email. Apologies. And I've been attaching an incremental patch too. Next patch revision is expected later today with support for plpython, plperl and pltcl. Okay, I shalln't do any more testing until the next patch. I should probably have worked on automating my tests more, but never got round to it. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Thom Brown thombr...@gmail.com writes: Okay, I shalln't do any more testing until the next patch. I should probably have worked on automating my tests more, but never got round to it. make installcheck :) That said, your test allow to spot OID problems that we can't add in the regression tests (OID being too volatile would break them), and I have to look at how to add regression tests for the other pls support… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 16 March 2012 12:07, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Thom Brown thombr...@gmail.com writes: Okay, I shalln't do any more testing until the next patch. I should probably have worked on automating my tests more, but never got round to it. make installcheck :) That said, your test allow to spot OID problems that we can't add in the regression tests (OID being too volatile would break them), and I have to look at how to add regression tests for the other pls support… Yes, that's why I don't use the regression tests. :) Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Andres Freund and...@anarazel.de writes: On Thursday, March 15, 2012 10:58:49 PM Dimitri Fontaine wrote: I tricked that in the grammar, the type is called cmdtrigger but I though it wouldn't be a good choice for the SQL statement. Hm. I am decidedly unhappy with that grammar hackery... But then maybe I am squeamish. Multi-word type names are a serious pain in the ass; they require hackery in a lot of places. We support the ones that the SQL spec requires us to, but I will object in the strongest terms to inventing any that are not required by spec. I object in even stronger terms to the incredibly klugy way you did it here. If you think cmdtrigger isn't a good name maybe you should have picked a different one to start with. While I'm looking at the grammar ... it also seems like a serious PITA from a maintenance standpoint that we're now going to have to adjust the CREATE COMMAND TRIGGER productions every time somebody thinks of a new SQL command. Maybe we should drop this whole idea of specifying which commands a trigger acts on at the SQL level, and just have one-size-fits-all command triggers. Or perhaps have the selection be on the basis of strings that are matched to command tags, instead of grammar constructs. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Friday, March 16, 2012 02:50:55 PM Tom Lane wrote: While I'm looking at the grammar ... it also seems like a serious PITA from a maintenance standpoint that we're now going to have to adjust the CREATE COMMAND TRIGGER productions every time somebody thinks of a new SQL command. I don't find that argument really convincing. The current state of the patch will often require attention to command triggers anyway... Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Andres Freund and...@anarazel.de writes: On Friday, March 16, 2012 02:50:55 PM Tom Lane wrote: While I'm looking at the grammar ... it also seems like a serious PITA from a maintenance standpoint that we're now going to have to adjust the CREATE COMMAND TRIGGER productions every time somebody thinks of a new SQL command. I don't find that argument really convincing. Well, how about just plain parser size bloat? Did anyone look at how much bigger gram.o becomes with this? Bigger parser - slower, for everybody, whether they care about this feature or not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Tom Lane t...@sss.pgh.pa.us writes: Multi-word type names are a serious pain in the ass; they require hackery in a lot of places. We support the ones that the SQL spec requires us to, but I will object in the strongest terms to inventing any that are not required by spec. I object in even stronger terms to the incredibly klugy way you did it here. Ok, it's so klugy that removing the support from the parser is going to be easy. If you think cmdtrigger isn't a good name maybe you should have picked a different one to start with. Well, I think it's a good internal name. I'm not too sure about exposing it, the only reason why it's a good name is because it's a single not too long word, after all. Not very “SQLish”. I'm putting cmdtrigger as the user visible name in the next version of the patch, if you come up with something potentially more user friendly feel free to suggest. While I'm looking at the grammar ... it also seems like a serious PITA from a maintenance standpoint that we're now going to have to adjust the CREATE COMMAND TRIGGER productions every time somebody thinks of a new SQL command. Maybe we should drop this whole idea of specifying which commands a trigger acts on at the SQL level, and just have one-size-fits-all command triggers. Or perhaps have the selection be on the basis of strings that are matched to command tags, instead of grammar constructs. The only advantage of doing it this way is giving the user an early error when he's trying to attach to a non-supported command. I wouldn't want to remove that list only to find myself adding a list of non supported commands so that we can still refuse creating the useless command trigger. And as Andres said, adding command trigger support to a new command isn't exactly transparent (it's still mostly mechanical though), so that does not seems so big a pain to me. Of course I have been having my head in there for a long time now… Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On Fri, Mar 16, 2012 at 7:42 AM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: I don’t know if this was a problem before that I didn’t spot (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE show a command tag of ALTER TABLE for ALTER FOREIGN TABLE statements where the column is renamed: I don’t think this is the fault of the trigger code because it actually says ALTER TABLE at the bottom, suggesting it’s something already present. This isn’t the case when adding or dropping columns. Any comments? We're building command trigger on top of the existing code. From the grammar we can see that an alter table and an alter foreign table are processed as the same command. This seems pretty dicey. I understand your position that it can't be the job of the command triggers patch to fix every infelicity of the backend, but on the flip side, code reuse is a good thing. We want to increase, not decrease, the number of places where the same code can be used to implement multiple commands that do related things; and there has to be some way to do that without breaking command triggers. Moreover, we really don't want the details of how things are handled internally to be user-visible, because sometimes we refactor things to improve the quality of our code, and I don't want to get bug reports when we do that... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Robert Haas robertmh...@gmail.com writes: there has to be some way to do that without breaking command triggers. Sure, special case the switch branch in utility.c so as to return a different command tag for ALTER TABLE and ALTER FOREIGN TABLE. For precedents, see AlterObjectTypeCommandTag(ObjectType objtype) and case T_DropStmt: switch (((DropStmt *) parsetree)-removeType) case T_DefineStmt: switch (((DefineStmt *) parsetree)-kind) So, do we want to do the same thing for ALTER FOREIGN TABLE, and should I do that in the command triggers patch? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: If you think cmdtrigger isn't a good name maybe you should have picked a different one to start with. Well, I think it's a good internal name. I'm not too sure about exposing it, the only reason why it's a good name is because it's a single not too long word, after all. Not very âSQLishâ. I'm putting cmdtrigger as the user visible name in the next version of the patch, if you come up with something potentially more user friendly feel free to suggest. How about commandtrigger or command_trigger? Typing a few more characters in this context doesn't seem like a deal-breaker to me. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 16 March 2012 16:26, Tom Lane t...@sss.pgh.pa.us wrote: Dimitri Fontaine dimi...@2ndquadrant.fr writes: Tom Lane t...@sss.pgh.pa.us writes: If you think cmdtrigger isn't a good name maybe you should have picked a different one to start with. Well, I think it's a good internal name. I'm not too sure about exposing it, the only reason why it's a good name is because it's a single not too long word, after all. Not very “SQLish”. I'm putting cmdtrigger as the user visible name in the next version of the patch, if you come up with something potentially more user friendly feel free to suggest. How about commandtrigger or command_trigger? Typing a few more characters in this context doesn't seem like a deal-breaker to me. +1 No objections to either of those suggestions, although I'd lean towards the one without the underscore, not for any technical reason. There is a precedent for a type with an underscore in its name (txid_snapshot) but seems to be the exception. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 15 March 2012 18:13, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Hi, I guess it's time to start a new thread here. Please find attached version 16 of the command trigger patch, with augmented documentation and “magic variable” support (TG_WHEN, TG_OBJECTID and such). The current version of the patch only supports PLpgSQL, I need to add support for the other languages in core but I though Thom would like to be able to play with a new patch before I finish plpython, plperl and pltcl support. This patch also includes edits following latest reviews from both Thom, Andres and Robert, in particular ANY command triggers are now called from the same place as specific command triggers and receive the same parameters. Good to see that ANY COMMAND triggers contain everything the specific triggers have. I've completed a complete re-run of all my testing. Note: incremental patch attached for the following section... -START The docs have an excessive opening varlistentry tag. The docs also list ALTER CAST as an option, which it isn't. There's an old version of a paragraph included, immediately followed by its revised version. It begins with Triggers on ANY command The example given for the abort_any_command function has a typo. The RAISE statement should have a comma after the closing single quote instead of %. In doc/src/sgml/plpgsql.sgml: “The command trigger function return's value is not used.” should be “The command trigger function’s return value is not used.” “This example trigger just raise a...” should be “This example trigger just raises a...” The example procedure isn't called correctly in the create command trigger statement below it. It refers to it at any_snitch, but the function is just named snitch. Also the style is inconsistent with the other trigger functions further up the page, such as putting the function language last, showing the return type on the same line as the CREATE FUNCTION line and using upper-case lettering for keywords. I don’t understand how functions can return a type of “command trigger”. This certainly works, but I’ve never seen a type consisting of more than one word. Could you explain this for me? This is also at odds with the error message in src/backend/commands/cmdtrigger.c: errmsg(function \%s\ must return type \trigger\, Should be “command trigger” as a regular trigger can’t be used on command triggers. END At this moment in time, CTAS is still outstanding. Is the plan to try to get that in for this release, or as an enhancement in 9.3? I don’t know if this was a problem before that I didn’t spot (probably), but triggers for both ANY COMMAND and ALTER FOREIGN TABLE show a command tag of ALTER TABLE for ALTER FOREIGN TABLE statements where the column is renamed: thom@test=# ALTER FOREIGN TABLE test.dict2 RENAME COLUMN word TO words; NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER TABLE' objectid=16569 schemaname='test' objectname='dict2' NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER TABLE' objectid=16569 schemaname='test' objectname='dict2' NOTICE: Command trigger: tg_when='AFTER' cmd_tag='ALTER TABLE' objectid=16569 schemaname='test' objectname='dict2' NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER TABLE' objectid=16569 schemaname='test' objectname='dict2' ALTER TABLE I don’t think this is the fault of the trigger code because it actually says ALTER TABLE at the bottom, suggesting it’s something already present. This isn’t the case when adding or dropping columns. Any comments? Altering the properties of a function (such as cost, security definer, whether it’s stable etc) doesn’t report the function’s OID: thom@test=# ALTER FUNCTION test.testfunc2() COST 77; NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER FUNCTION' objectid=NULL schemaname='test' objectname='testfunc2' NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER FUNCTION' objectid=NULL schemaname='test' objectname='testfunc2' NOTICE: Command trigger: tg_when='AFTER' cmd_tag='ALTER FUNCTION' objectid=NULL schemaname='test' objectname='testfunc2' NOTICE: Command trigger on any: tg_when='AFTER' cmd_tag='ALTER FUNCTION' objectid=NULL schemaname='test' objectname='testfunc2' ALTER FUNCTION I get a garbage objectname for AFTER ANY COMMAND triggers on ALTER TEXT SEARCH DICTIONARY when changing its options. It doesn’t show it in the below example because I can’t get it displaying in plain text, but where the objectname is blank is where I’m seeing unicode a square containing “0074” 63 times in a row: thom@test=# ALTER TEXT SEARCH DICTIONARY testnew.test_stem2 ( StopWords = dutch ); NOTICE: Command trigger on any: tg_when='BEFORE' cmd_tag='ALTER TEXT SEARCH DICTIONARY' objectid=16617 schemaname='testnew' objectname='test_stem2' NOTICE: Command trigger: tg_when='BEFORE' cmd_tag='ALTER TEXT SEARCH DICTIONARY' objectid=16617 schemaname='testnew' objectname='test_stem2' NOTICE:
Re: [HACKERS] Command Triggers, v16
Thanks for testing this new version (again). A quick answer now, I'll send another patch tomorrow. Thom Brown thombr...@gmail.com writes: I don’t understand how functions can return a type of “command trigger”. This certainly works, but I’ve never seen a type consisting of more than one word. Could you explain this for me? This is also I tricked that in the grammar, the type is called cmdtrigger but I though it wouldn't be a good choice for the SQL statement. at odds with the error message in src/backend/commands/cmdtrigger.c: errmsg(function \%s\ must return type \trigger\, I realized I needed another trigger like data type after I had worked this message, I need to get back on it, thanks. At this moment in time, CTAS is still outstanding. Is the plan to try to get that in for this release, or as an enhancement in 9.3? The plan is to get CTAS as a utility command in 9.2 then update the command trigger patch to benefit from the new situation. We've been wondering about making its own commit fest entry for that patch, it's now clear in my mind, that needs to happen. Stay tuned, follow up email due tomorrow. -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
Dimitri Fontaine dimi...@2ndquadrant.fr writes: At this moment in time, CTAS is still outstanding. Is the plan to try to get that in for this release, or as an enhancement in 9.3? The plan is to get CTAS as a utility command in 9.2 then update the command trigger patch to benefit from the new situation. We've been wondering about making its own commit fest entry for that patch, it's now clear in my mind, that needs to happen. https://commitfest.postgresql.org/action/patch_view?id=823 Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Command Triggers, v16
On 15 March 2012 22:06, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Dimitri Fontaine dimi...@2ndquadrant.fr writes: At this moment in time, CTAS is still outstanding. Is the plan to try to get that in for this release, or as an enhancement in 9.3? The plan is to get CTAS as a utility command in 9.2 then update the command trigger patch to benefit from the new situation. We've been wondering about making its own commit fest entry for that patch, it's now clear in my mind, that needs to happen. https://commitfest.postgresql.org/action/patch_view?id=823 Looks like the ctas-on-command-triggers-01.patch patch needs re-basing. Thom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
