CREATE EVENT TRIGGER syntax

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 /messages/by-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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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 /messages/by-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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers