Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
