From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: adminpack and pg_catalog |
Date: | 2006-10-20 20:18:56 |
Message-ID: | 1161375536.13928.43.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2006-10-20 20:19:38 | Re: Multiple postmaster + RPM + locale issues |
Previous Message | Neil Conway | 2006-10-20 20:17:05 | Re: adminpack and pg_catalog |