Skip to main content
Use FUNCTION LOAD to register a library of functions in the database. The payload is the library source code. It must begin with a shebang line naming the engine and the library, such as #!lua name=mylib, and register each function with redis.register_function, giving it a name, a callback, and optional flags such as no-writes. The reply is the library name. allow-key-locking is one of those flags. It opts a function out of the global lock so that a call locks only the keys passed in its key list, which lets calls on disjoint keys run in parallel. Unlike Lua scripts, where the flag goes on the shebang line, it is declared per function in redis.register_function, and it is fixed until the library is loaded again. See Key-Based Locking. Whether or not you set that flag, write functions so that every key they touch arrives in the key list rather than being assembled from ARGV inside the function, since an undeclared key can force a disk read while the lock is held. See Dynamic Keys and Latency. Loading fails when the library name is already in use unless REPLACE is given, which is how you deploy a new version of a library. Once loaded, functions are called by name with FCALL or FCALL_RO. Unlike scripts cached by SCRIPT LOAD, libraries are part of the dataset, so they survive restarts and do not need to be re-sent by clients.

Syntax

Arguments

Response

The reply reports the result of the operation. Error replies have the same shape in RESP2 and RESP3 and are surfaced as exceptions by the SDKs below.
Client libraries often decode bulk strings, maps, sets, and numeric strings into language-native values. The table describes the Redis wire reply.

Examples

TCP examples use the TLS REDIS_URL from the Upstash console. REST examples use UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN.
This command is not supported yet in upstash_redis.