Re: language handlers in public schema?

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>
>>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.
>>
>>
>
>Why --- what else is needed beyond the addition of those clauses to the
>one query?
>
>

There are tests for both the function and the handler based on
finfo->dobj.namespace->dump that inhibit output if we're in the catalog
schema.

If we go down this path ISTM the simplest thing would be to add a field
to the FuncInfo object to allow it to be marked as a a handler/validator.

Also, I think pg_dump *never* quotes the handler name or qualifies it
with a schema name - that looks like it might be a bug, regardless of this.

>
>
>>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.
>>
>>
>
>I don't see the need. If they were in public before, they can stay
>there --- or the DBA can run createlang before running pg_restore to
>put them where he wants.
>
>
>
>

OK, I'm all for a simple life.

cheers

andrew