[jOOQ/jOOQ#6956] Add support for CREATE, DROP TRIGGER

- Added DSL (CREATE, DROP)
- Added parser support (DROP)
- Added simple integration tests

jOOQ/src/main/java/org/jooq/CreateTriggerActionStep.java

@@ -37,54 +37,58 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerActionStep {
 
-    /**
-     * Add the <code>STATEMENT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerFinalStep statement(Statement... statement);
 
-    /**
-     * Add the <code>STATEMENT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerFinalStep statement(Collection<? extends Statement> statement);
 
-    /**
-     * Add the <code>STATEMENT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerFinalStep statement(Statement statement);
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerEventOfStep.java

@@ -37,61 +37,65 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerEventOfStep extends CreateTriggerEventOrStep {
 
-    /**
-     * Add the <code>OF</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep of(String... of);
 
-    /**
-     * Add the <code>OF</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep of(Name... of);
 
-    /**
-     * Add the <code>OF</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep of(Field<?>... of);
 
-    /**
-     * Add the <code>OF</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep of(Collection<? extends Field<?>> of);
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerEventOnStep.java

@@ -37,54 +37,58 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerEventOnStep {
 
-    /**
-     * Add the <code>ON</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep on(@Stringly.Name String on);
 
-    /**
-     * Add the <code>ON</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep on(Name on);
 
-    /**
-     * Add the <code>ON</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep on(Table<?> on);
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerEventOrStep.java

@@ -37,54 +37,58 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerEventOrStep extends CreateTriggerEventOnStep {
 
-    /**
-     * Add the <code>OR INSERT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep orInsert();
 
-    /**
-     * Add the <code>OR UPDATE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOfStep orUpdate();
 
-    /**
-     * Add the <code>OR DELETE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep orDelete();
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerEventStep.java

@@ -37,96 +37,100 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerEventStep {
 
-    /**
-     * Add the <code>BEFORE INSERT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep beforeInsert();
 
-    /**
-     * Add the <code>AFTER INSERT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep afterInsert();
 
-    /**
-     * Add the <code>INSTEAD OF INSERT</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep insteadOfInsert();
 
-    /**
-     * Add the <code>BEFORE UPDATE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOfStep beforeUpdate();
 
-    /**
-     * Add the <code>AFTER UPDATE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOfStep afterUpdate();
 
-    /**
-     * Add the <code>INSTEAD OF UPDATE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOfStep insteadOfUpdate();
 
-    /**
-     * Add the <code>BEFORE DELETE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep beforeDelete();
 
-    /**
-     * Add the <code>AFTER DELETE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep afterDelete();
 
-    /**
-     * Add the <code>INSTEAD OF DELETE</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerEventOrStep insteadOfDelete();
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerFinalStep.java

@@ -37,33 +37,37 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerFinalStep extends DDLQuery {
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerForStep.java

@@ -37,40 +37,44 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerForStep extends CreateTriggerWhenStep {
 
-    /**
-     * Add the <code>FOR EACH ROW</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerWhenStep forEachRow();
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerReferencingStep.java

@@ -37,61 +37,65 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerReferencingStep extends CreateTriggerForStep {
 
-    /**
-     * Add the <code>REFERENCING OLD AS</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep referencingOldAs(@Stringly.Name String referencingOldAs);
 
-    /**
-     * Add the <code>REFERENCING OLD AS</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep referencingOldAs(Name referencingOldAs);
 
-    /**
-     * Add the <code>REFERENCING NEW AS</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep referencingNewAs(@Stringly.Name String referencingNewAs);
 
-    /**
-     * Add the <code>REFERENCING NEW AS</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerReferencingStep referencingNewAs(Name referencingNewAs);
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/CreateTriggerWhenStep.java

@@ -37,101 +37,105 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>CREATE TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface CreateTriggerWhenStep extends CreateTriggerActionStep {
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerActionStep when(Field<Boolean> when);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerActionStep when(Condition... when);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerActionStep when(Collection<? extends Condition> when);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     */
-    @Support
-    @NotNull
-    CreateTriggerActionStep when(Condition when);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     *
-     * @see SQL
-     */
-    @Support
-    @PlainSQL
-    @NotNull
-    CreateTriggerActionStep when(@Stringly.SQL String when, QueryPart... parts);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     *
-     * @see SQL
-     */
-    @Support
-    @PlainSQL
-    @NotNull
-    CreateTriggerActionStep when(@Stringly.SQL String when, Object... bindings);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     *
-     * @see SQL
-     */
-    @Support
-    @PlainSQL
-    @NotNull
-    CreateTriggerActionStep when(@Stringly.SQL String when);
 
-    /**
-     * Add the <code>WHEN</code> clause to the <code>CREATE TRIGGER</code> statement.
-     *
-     * @see SQL
-     */
-    @Support
-    @PlainSQL
-    @NotNull
-    CreateTriggerActionStep when(SQL when);
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

jOOQ/src/main/java/org/jooq/DropTriggerFinalStep.java

@@ -37,33 +37,37 @@
  */
 package org.jooq;
 
-import static org.jooq.SQLDialect.*;
 
-import java.util.*;
 
-import org.jetbrains.annotations.*;
 
-/**
- * A step in the construction of the <code>DROP TRIGGER</code> statement.
- * <p>
- * <h3>Referencing <code>XYZ*Step</code> types directly from client code</h3>
- * <p>
- * It is usually not recommended to reference any <code>XYZ*Step</code> types
- * directly from client code, or assign them to local variables. When writing
- * dynamic SQL, creating a statement's components dynamically, and passing them
- * to the DSL API statically is usually a better choice. See the manual's
- * section about dynamic SQL for details: <a href=
- * "https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql">https://www.jooq.org/doc/latest/manual/sql-building/dynamic-sql</a>.
- * <p>
- * Drawbacks of referencing the <code>XYZ*Step</code> types directly:
- * <ul>
- * <li>They're operating on mutable implementations (as of jOOQ 3.x)</li>
- * <li>They're less composable and not easy to get right when dynamic SQL gets
- * complex</li>
- * <li>They're less readable</li>
- * <li>They might have binary incompatible changes between minor releases</li>
- * </ul>
- */
-@SuppressWarnings({ "unused" })
-public interface DropTriggerFinalStep extends DDLQuery {
-}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+