Re: language handlers in public schema?

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.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