Lock down search_path of functions

[svenklemm]

Functions referencing objects without schema are susceptible to accessing unintented objects depending on the search_path they are executed with. This patch adds a search_path to all the SQL and PLPGSQL functions to ensure the intended objects are accessed.

[za-arthur]

@svenklemm thank you for the contribution!

Currently pg_repack sets hardcoded search_path on every connection:

pg_repack/bin/pgut/pgut.c

Line 550 in 306b0d4

pgut_command(conn, "SET search_path TO pg_catalog, pg_temp, public", 0, NULL);

Does the PR improve handling of issue of calling unintented objects? BTW there are still views repack.primary_keys and repack.tables, which can call unintended objects. AFAIK it isn't possible to set search_path during CREATE VIEW, but because pg_repack already sets hardcoded search_path all views and functions calls should be handled.

[svenklemm]

During view creation object references are pinned to the objects according to the search path during creation. But this does not apply to indirect references, e.g. unspecified object references in functions called in a view. With explicit search_path like that things used by pg_repack binary are safe. This is hardening for callers outside of the binary using the views provided by pg_repack.