OK.
---
Christopher Kings-Lynne wrote:
> Only if you commit my pg_dump patch that's in the queue.
>
> Chris
>
> Bruce Momjian wrote:
>
> > Is this fixed in 7.5?
> >
> > ---
Only if you commit my pg_dump patch that's in the queue.
Chris
Bruce Momjian wrote:
Is this fixed in 7.5?
---
Christopher Kings-Lynne wrote:
If you do this sequence of events, you get a failure to restore:
1. As superuser, do t
Is this fixed in 7.5?
---
Christopher Kings-Lynne wrote:
> If you do this sequence of events, you get a failure to restore:
>
> 1. As superuser, do this:
>
> test2=# CREATE FUNCTION plpgsql_call_handler () RETURNS language
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> How about we allow changing owner of lanugages so I can fix this problem?
> Is it safe for me to just update the catalogs?
Sure.
regards, tom lane
---(end of broadcast)--
If you do this sequence of events, you get a failure to restore:
This is not a pg_dump bug.
Possibly ALTER USER should refuse to drop someone's superuserness if
there is content in the database that depends on his superuserness,
but I don't see how to enforce that.
How about we allow changing owne
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> If you do this sequence of events, you get a failure to restore:
This is not a pg_dump bug.
Possibly ALTER USER should refuse to drop someone's superuserness if
there is content in the database that depends on his superuserness,
but I don't se
If you do this sequence of events, you get a failure to restore:
1. As superuser, do this:
test2=# CREATE FUNCTION plpgsql_call_handler () RETURNS language_handler
test2-# AS '$libdir/plpgsql.so', 'plpgsql_call_handler'
test2-# LANGUAGE c;
CREATE FUNCTION
2. Drop privs.
test2=# alter use
