Re: language handlers in public schema?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: language handlers in public schema?
Date: 2005-06-26 19:52:10
Message-ID: 42BF076A.7030708@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:

>regression=# explain analyze select * from pg_proc WHERE NOT proisagg AND (pronamespace != (select oid from pg_namespace where nspname = 'pg_catalog')
>regression(# OR oid in (select lanplcallfoid from pg_language) OR oid in (select lanvalidator from pg_language));
>
>
>

Yeah. I think we'd need to add "where langlcallfoid != 0" so we don't
pick up the internal/C/sql handlers. However, on closer inspection it
appears that doind all this in pg_dump would be lots more invasive than
I first thought. An alternative would be to adopt AndrewSN's suggestion
of an extra schema (or possibly two) created by initdb where we put
extra stuff. That would mean a very simple addition to initdb.c and no
changes to pg_dump, except ...

>Next question is whether there are any other places that would be
>affected besides createlang/droplang. I can't think of any offhand,
>but ...
>
>
>
>

me either, but I wonder if we should provide an option on pg_dump to
restore function handlers found in public to whatever we decide about
the above.

thoughts?

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2005-06-26 19:52:26 Re: pl/pgsql: END verbosity
Previous Message Tom Lane 2005-06-26 19:20:41 Re: Implementing SQL/PSM for PG 8.2

Browse pgsql-patches by date

  From Date Subject
Next Message Pavel Stehule 2005-06-26 19:52:26 Re: pl/pgsql: END verbosity
Previous Message Alvaro Herrera 2005-06-26 19:16:22 Re: limiting connections per user/database