Re: language handlers in public schema? - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: language handlers in public schema?
Date
Msg-id 42BF10B7.2060907@dunslane.net
Whole thread Raw
In response to Re: language handlers in public schema?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Implementing SQL/PSM for PG 8.2
Next
From: Andrew Dunstan
Date:
Subject: Re: Implementing SQL/PSM for PG 8.2