Postgres Pro Enterprise
1817161514131211
Postgres Pro Standard
1817161514131211
PostgreSQL
1817161514131211
RUENRU EN
DROP PROCEDURE
Пред. НаверхКоманды SQLНачало След.

DROP PROCEDURE

DROP PROCEDURE — удалить процедуру

Синтаксис

DROP PROCEDURE [ IF EXISTS ] имя [ ( [ [ режим_аргумента ] [ имя_аргумента ] тип_аргумента [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

Описание

DROP PROCEDURE удаляет определение одной или нескольких существующих процедур. Пользователь, выполняющий эту команду, должен быть владельцем процедур(ы). Помимо имени процедуры обычно требуется указать типы её аргументов, так как в базе данных могут существовать несколько процедур с одним именем, но с разными списками аргументов.

Параметры

IF EXISTS

Не считать ошибкой, если процедура не существует. В этом случае будет выдано замечание.

имя

Имя существующей процедуры (возможно, дополненное схемой).

режим_аргумента

Режим аргумента: IN или VARIADIC. По умолчанию подразумевается IN (но учтите следующие замечания).

имя_аргумента

Имя аргумента. Заметьте, что на самом деле DROP PROCEDURE не обращает внимание на имена аргументов, так как для идентификации процедуры используются только их типы.

тип_аргумента

Тип данных аргумента или аргументов (возможно, дополненный именем схемы), если таковые имеются. Подробности следуют ниже.

CASCADE

Автоматически удалять объекты, зависящие от данной процедуры, и, в свою очередь, все зависящие от них объекты (см. Раздел 5.14).

RESTRICT

Отказать в удалении процедуры, если от неё зависят какие-либо объекты. Это поведение по умолчанию.

Примечания

Если существует только одна процедура с заданным именем, список аргументов можно опустить. В этом случае также следует опустить скобки.

В PostgreSQL достаточно перечислить только входные аргументы (включая аргументы INOUT), так как одноимённые подпрограммы не могут иметь одинаковые списки входных аргументов. Команда DROP на самом деле не проверяет корректность типов для выходных аргументов (OUT), поэтому аргументы, помеченные OUT, ни на что не влияют. Тем не менее, рекомендуется указывать их для согласованности с соответствующей командой CREATE.

Для совместимости со стандартом SQL также возможно записать все аргументы любых типов (включая аргументы OUT) без маркеров режим_аргумента. В этом случае типы выходных аргументов (OUT) будут сверяться с указанными при создании. При этом возникает неоднозначность, так как в случае отсутствия маркеров режим_аргумента в списке аргументов неясно, какое поведение ожидается. Команда DROP попытается выполнить поиск обоими способами и выдаст ошибку, если будут найдены две разные процедуры. Для исключения такой неоднозначности рекомендуется явно указывать маркеры IN, а не полагаться на то, что они подразумеваются по умолчанию; таким образом будет выбираться традиционное поведение PostgreSQL.

Описанные правила поиска действуют также с другими командами, работающими с существующими процедурами, например ALTER PROCEDURE и COMMENT ON PROCEDURE.

Примеры

Если существует только одна процедура do_db_maintenance, этой команды будет достаточно, чтобы удалить её: 

DROP PROCEDURE do_db_maintenance;

При таком определении процедуры: 

CREATE PROCEDURE do_db_maintenance(IN target_schema text, OUT results text) ...

любая из следующих команд удалит её: 

DROP PROCEDURE do_db_maintenance(IN target_schema text, OUT results text);
DROP PROCEDURE do_db_maintenance(IN text, OUT text);
DROP PROCEDURE do_db_maintenance(IN text);
DROP PROCEDURE do_db_maintenance(text);
DROP PROCEDURE do_db_maintenance(text, text);  -- возможна неоднозначность

Однако последняя команда будет неоднозначной, если существует, например, такая процедура: 

CREATE PROCEDURE do_db_maintenance(IN target_schema text, IN options text) ...

Совместимость

Эта команда соответствует стандарту SQL, но дополнена расширениями Postgres Pro:

  • Стандарт позволяет удалять с помощью этой команды только одну процедуру.

  • Указание IF EXISTS является расширением.

  • Возможность указывать режимы и имена аргументов является расширением, а правила поиска при указании режимов могут меняться.

Пред. Наверх След.
DROP POLICY Начало DROP PROFILE
DROP PROCEDURE
Prev UpSQL CommandsHome Next

DROP PROCEDURE

DROP PROCEDURE — remove a procedure

Synopsis

DROP PROCEDURE [ IF EXISTS ] name [ ( [ [ argmode ] [ argname ] argtype [, ...] ] ) ] [, ...]
    [ CASCADE | RESTRICT ]

Description

DROP PROCEDURE removes the definition of one or more existing procedures. To execute this command the user must be the owner of the procedure(s). The argument types to the procedure(s) usually must be specified, since several different procedures can exist with the same name and different argument lists.

Parameters

IF EXISTS

Do not throw an error if the procedure does not exist. A notice is issued in this case.

name

The name (optionally schema-qualified) of an existing procedure.

argmode

The mode of an argument: IN, OUT, INOUT, or VARIADIC. If omitted, the default is IN (but see below).

argname

The name of an argument. Note that DROP PROCEDURE does not actually pay any attention to argument names, since only the argument data types are used to determine the procedure's identity.

argtype

The data type(s) of the procedure's arguments (optionally schema-qualified), if any. See below for details.

CASCADE

Automatically drop objects that depend on the procedure, and in turn all objects that depend on those objects (see Section 5.14).

RESTRICT

Refuse to drop the procedure if any objects depend on it. This is the default.

Notes

If there is only one procedure of the given name, the argument list can be omitted. Omit the parentheses too in this case.

In PostgreSQL, it's sufficient to list the input (including INOUT) arguments, because no two routines of the same name are allowed to share the same input-argument list. Moreover, the DROP command will not actually check that you wrote the types of OUT arguments correctly; so any arguments that are explicitly marked OUT are just noise. But writing them is recommendable for consistency with the corresponding CREATE command.

For compatibility with the SQL standard, it is also allowed to write all the argument data types (including those of OUT arguments) without any argmode markers. When this is done, the types of the procedure's OUT argument(s) will be verified against the command. This provision creates an ambiguity, in that when the argument list contains no argmode markers, it's unclear which rule is intended. The DROP command will attempt the lookup both ways, and will throw an error if two different procedures are found. To avoid the risk of such ambiguity, it's recommendable to write IN markers explicitly rather than letting them be defaulted, thus forcing the traditional PostgreSQL interpretation to be used.

The lookup rules just explained are also used by other commands that act on existing procedures, such as ALTER PROCEDURE and COMMENT ON PROCEDURE.

Examples

If there is only one procedure do_db_maintenance, this command is sufficient to drop it: 

DROP PROCEDURE do_db_maintenance;

Given this procedure definition: 

CREATE PROCEDURE do_db_maintenance(IN target_schema text, OUT results text) ...

any one of these commands would work to drop it: 

DROP PROCEDURE do_db_maintenance(IN target_schema text, OUT results text);
DROP PROCEDURE do_db_maintenance(IN text, OUT text);
DROP PROCEDURE do_db_maintenance(IN text);
DROP PROCEDURE do_db_maintenance(text);
DROP PROCEDURE do_db_maintenance(text, text);  -- potentially ambiguous

However, the last example would be ambiguous if there is also, say, 

CREATE PROCEDURE do_db_maintenance(IN target_schema text, IN options text) ...

Compatibility

This command conforms to the SQL standard, with these Postgres Pro extensions:

  • The standard only allows one procedure to be dropped per command.

  • The IF EXISTS option is an extension.

  • The ability to specify argument modes and names is an extension, and the lookup rules differ when modes are given.

Prev Up Next
DROP POLICY Home DROP PROFILE
FAQ