Drop Table

Data Manipulation

Synopsis

Removes the named virtual table from the entry. If it was the entry's current output table, output reverts to the untyped Map.

Schema

- drop_table:
    name: <string>
    description: <text>
    if: <script>
    tag: <string>
    disabled: <boolean>
    ignore_failure: <boolean>
    on_failure: <processor[]>
    on_success: <processor[]>

Configuration

Field	Required	Default	Description
name	Y		Table to remove. Must be one of the 37 registered tables (see Create Table), matched case-insensitively. Supports templating, e.g. name: "{{table}}".
description	N		Explanatory note.
if	N		Condition that must be true for the processor to run.
tag	N		Identifier for this processor instance.
disabled	N	false	When true, the processor is skipped.
ignore_failure	N	false	Continue pipeline processing if the processor fails.
on_failure	N		See Handling Failures.
on_success	N		See Handling Success.

Details

What Gets Removed

drop_table deallocates the named table's backing struct from the entry entirely — not just its contents, the member itself. A subsequent $<table>.Field write on that table re-creates it, empty, and the write lands in the new table. A read, delete, use_table or to_map of the dropped table behaves as if the table had never been created, until a create_table or a write allocates it again.

If the dropped table was the entry's current output table (selected by Use Table), output reverts to the untyped Map automatically — the same effect as use_table with name: "map". Dropping a table that is allocated but was never selected as output has no effect on what the entry marshals; it only removes that table.

Failure Mode

Dropping a table that was never create_table-d on this entry is a no-op — the member is already absent. Dropping a name that is not one of the 37 registered tables fails the processor with unknown virtual table: "<name>", same as create_table and truncate_table. Add ignore_failure: true to treat that as a soft skip.

Examples

Dropping the Current Output Table Reverts to Map

Selecting Syslog as output, then dropping it...	{ "message": "raw line" } - create_table: name: Syslog - set: field: $syslog.SyslogMessage value: "{{{message}}}" - use_table: name: Syslog - drop_table: name: Syslog
Output automatically reverts to Map — the Syslog table, and its SyslogMessage value, are gone entirely; message ships from Map instead...	{ "message": "raw line" }

Dropping a Table That Isn't the Output Leaves Output Unaffected

Two tables are allocated; only CommonSecurityLog is selected as output. Dropping the other, unselected table...	{} - create_table: name: Syslog - create_table: name: CommonSecurityLog - set: field: $commonsecuritylog.Activity value: "login" - use_table: name: CommonSecurityLog - drop_table: name: Syslog
...has no effect on the marshal source — CommonSecurityLog still ships...	{ "Activity": "login" }

No-Op on a Table That Was Never Created

Dropping Syslog before anything has ever create_table-d it...	{ "message": "untouched" } - drop_table: name: Syslog
No error is raised — the member is already absent, and the event passes through unmodified...	{ "message": "untouched" }

Failing on an Unknown Table Name

Naming a table that isn't one of the 37 registered schemas...	{} - drop_table: name: Frobnicate ignore_failure: true
Frobnicate isn't a registered table, so — unlike an uncreated but known table — this fails; ignore_failure skips the failure...	{}