Neil Conway wrote:
> 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.
>
.. which appears simply pragmatic, taken that it features server
maintenance functions, not functions usually called from user applications.
>
>> 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.
>
Please note that adminpack is intended for administrator's use, and
should be robust to (i.e. not dependent on) search path. We previously
had this dependency in pgadmin, and found it sucks. Putting the stuff in
pg_catalog works as desired and has no negative effects (apart from the
contrib not working after pg_dump/pg_restore if not installed, which is
expected behaviour anyway).
However, adminpack was crippled to the edge of usability for me already,
I'm prepared to see it fade away further (Since there's still no
pg_terminate_backend available which is definitely needed, I regularly
need to install my personal adminpack).
Regards,
Andreas