Обсуждение: CREATE EVENT TRIGGER syntax
Hello, What is the purpose of the [ AND ... ] at the end of the WHEN clause? Is that for later releases, when presumably additional filter_variables will be introduced? Right now, if I add "AND tag IN ..." I get an ERROR: filter variable "tag" specified more than once Joe
Joe Abbate <jma@freedomcircle.com> writes: > What is the purpose of the [ AND ... ] at the end of the WHEN clause? > Is that for later releases, when presumably additional filter_variables > will be introduced? Right now, if I add "AND tag IN ..." I get an Yes. I had other filter variables in some versions of the patch, but we're yet to agree on a design for the things I wanted to solve with them. See http://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr for some worked out example of the CONTEXT part of the Event Trigger proposal. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Fri, Jul 19, 2013 at 05:12:16PM -0700, Dimitri Fontaine wrote: > Joe Abbate <jma@freedomcircle.com> writes: > > What is the purpose of the [ AND ... ] at the end of the WHEN clause? > > Is that for later releases, when presumably additional filter_variables > > will be introduced? Right now, if I add "AND tag IN ..." I get an > > Yes. I had other filter variables in some versions of the patch, but > we're yet to agree on a design for the things I wanted to solve with > them. > > See http://www.postgresql.org/message-id/m2txrsdzxa.fsf@2ndQuadrant.fr > for some worked out example of the CONTEXT part of the Event Trigger > proposal. So do we want to keep that "AND" in the 9.3beta and 9.4 documentation? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes: > So do we want to keep that "AND" in the 9.3beta and 9.4 documentation? The grammar as in gram.y still allows the AND form, and I think we're used to maintain documentation that matches the code here. So I think it makes sense to remove both capabilities as we failed to deliver any other filter. But if we wanted to clean that, what about having the grammar check for the only one item we support rather than waiting until into CreateEventTrigger() to ereport a syntax error? -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Mon, Aug 5, 2013 at 4:53 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Bruce Momjian <bruce@momjian.us> writes: >> So do we want to keep that "AND" in the 9.3beta and 9.4 documentation? > > The grammar as in gram.y still allows the AND form, and I think we're > used to maintain documentation that matches the code here. So I think it > makes sense to remove both capabilities as we failed to deliver any > other filter. > > But if we wanted to clean that, what about having the grammar check for > the only one item we support rather than waiting until into > CreateEventTrigger() to ereport a syntax error? I have found that it's generally better to recognize such errors in the post-parse phase rather than during parsing. When you start adding more options, that tends to quickly become the only workable option anyway. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Aug 9, 2013 at 09:12:03AM -0400, Robert Haas wrote: > On Mon, Aug 5, 2013 at 4:53 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > > Bruce Momjian <bruce@momjian.us> writes: > >> So do we want to keep that "AND" in the 9.3beta and 9.4 documentation? > > > > The grammar as in gram.y still allows the AND form, and I think we're > > used to maintain documentation that matches the code here. So I think it > > makes sense to remove both capabilities as we failed to deliver any > > other filter. > > > > But if we wanted to clean that, what about having the grammar check for > > the only one item we support rather than waiting until into > > CreateEventTrigger() to ereport a syntax error? > > I have found that it's generally better to recognize such errors in > the post-parse phase rather than during parsing. When you start > adding more options, that tends to quickly become the only workable > option anyway. OK, so I am assuming there is no additional work to do this area. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +