For testing purposes, I provide my own implementation of the now()
function which is public.now()
. Using search_path
to override the defau
The default function is "bound" at the time the default constraint is created. The view showing the unqualified name is simply abbreviating it.
This can be demonstrated by inserting rows before and after shadowing the function:
Set search_path to public,pg_catalog;
Create Temp Table foo (
test date not null default now()
);
Insert Into foo default values;
Create Function public.now() Returns timestamp with time zone Language SQL As $$
-- No idea why I chose this date.
Select '1942-05-09'::timestamp with time zone;
$$;
Insert Into foo default values;
Select * from foo;
Note that both rows (inserted before and after function creation) contain today's date, not the fake date.
Furthermore, creating a table with the above function already in scope, then trying to delete the function, results in a dependency error:
Set search_path to public,pg_catalog;
Create Function public.now() Returns timestamp with time zone Language SQL As $$
Select '1942-05-09'::timestamp with time zone;
$$;
Create Temp Table bar (
test date not null default now()
);
Insert Into bar default values;
Select * from bar;
-- Single row containing the dummy date rather than today
Drop Function public.now();
-- ERROR: cannot drop function now() because other objects depend on it
If the binding happened only on insert, there would be no such dependency.
Don't bother all that. Postgres sometimes is writing weired stuff after things are compiled. Especially Views are often changed beyound recognition.
And: now() and pg_catalog.now() is normally the very same. See:
CREATE OR REPLACE FUNCTION now()
RETURNS timestamp with time zone AS
'now'
LANGUAGE internal STABLE STRICT
COST 1;
ALTER FUNCTION now()
OWNER TO postgres;
COMMENT ON FUNCTION now() IS 'current transaction time';
Don't worry.
Default values are parsed at creation time (early binding!). What you see in psql, pgAdmin or other clients is a text representation but, in fact, the OID
of the function now()
at the time of creating the column default is stored in the system catalog pg_attrdef. I quote:
adbin pg_node_tree The internal representation of the column default value
adsrc text A human-readable representation of the default value
When you change the search_path, that causes Postgres to display the name of the function schema-qualified, since it would not be resolved correctly any more with the current search_path
.
Dump and restore are not concerned with your custom search_path
setting. They set it explicitly. So what you see is not related to the the dump / restore cycle.
Placing public
before pg_catalog
in the search_path
is a game of hazard. Underprivileged users (including yourself) are often allowed to write there and create functions that may inadvertently overrule system functions - with arbitrary (or malicious) outcome.
You want a dedicated schema with restricted access to override built-in functions. Use something like this instead:
SET search_path = override, pg_catalog, public;
Details in this related answer on dba.SE.