On Fri, 2006-10-20 at 05:52 +0100, Dave Page wrote:
> The adminpack was originally written and intended to become builtin
> functions
This is not unique to adminpack: several contrib modules might
eventually become (or have already become) builtins, but adminpack is
the only module that defines objects in the pg_catalog schema.
> pg_catalog was used to ensure compatibility in the future
This is again not unique to adminpack. If users install a contrib module
into a schema that is in their search path, then if the module is
subsequently moved to pg_catalog, no queries will need to be changed. If
users install a module into some schema that isn't in their search path
and use explicit schema references, they are essentially asking for
their application to break if the object moves to a different schema.
> > And as AndrewSN pointed out on IRC, it also breaks pg_dump.
>
> It does? In what way?
It breaks in the sense of "completely not working" :)
% pg_dump | grep file_write
% cd contrib/adminpack
% grep -A1 file_write adminpack.sql
CREATE FUNCTION pg_catalog.pg_file_write(text, text, bool) RETURNS
bigint AS '$libdir/adminpack', 'pg_file_write'LANGUAGE C VOLATILE STRICT;
% psql -f adminpack.sql
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
% pg_dump | grep file_write
%
-Neil
