Database Reference
In-Depth Information
= i_username;
$$ LANGUAGE plproxy SECURITY DEFINER;
Only a single
SELECT
is supported; for any other or more complex SQL statements,
you have to write a remote function and call it.
The third option is to still call a function similar to itself, but named differently. For
example, if you have a proxy function defined not in a separate proxy database, but
in a partition, you may want it to target the local database for some data:
CREATE OR REPLACE FUNCTION
public.get_user_email(i_username text) RETURNS
SETOF text AS $$
CLUSTER 'messaging';
RUN ON hashtext(i_username);
TARGET local.get_user_email;
$$ LANGUAGE plproxy SECURITY DEFINER;
In this setup, the local version of
get_user_email()
is in schema local on all par-
titions. Therefore, if one of the partitions connects back to the same database that it
is defined in, it avoids circular calling.
SPLIT - distributing array elements over several partitions
The last PL/Proxy statement is for cases where you want some bigger chunk of work
to be done in appropriate partitions. For example, if you have a function to create
several users in one call and you still want to be able to use it after partitioning, the
SPLIT statement is a way to tell PL/Proxy to split the arrays between the partitions
based on the partitioning function:
CREATE or REPLACE FUNCTION create_new_users(
IN i_username text[], IN i_pwdhash text[],
IN i_email text[],
OUT status int, OUT message text ) RETURNS
SETOF RECORD
AS $$
