| From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fixing pg_dump |
| Date: | 2004-06-28 02:09:01 |
| Message-ID: | 40DF7DBD.2050905@familyhealth.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> * Do we no longer worry about the SCHEMA AUTHORIZATION clause? I might
> set it to keep being issued in 'sql standard mode', but otherwise we
> cannot use it in dumps any more.
Actually, that's not true - I'm being silly. We can use the
AUTHORIZATION clause instead of ALTER SCHEMA ... OWNER TO :)
Another question:
We currently fully qualify DROP command with the namespace so that drops
will not accidentally modify the system catalogs. Shouldn't this also
be necessary on ALL non-CREATE commands?
ie. All ALTER, GRANT and REVOKE commands?
Otherwise, if the create table command associated with each of these
fails (for whatever reason), the script could happily carry on and
modify the system catalog tables?
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-06-28 02:09:08 | Re: Fixing pg_dump |
| Previous Message | Christopher Kings-Lynne | 2004-06-28 01:45:53 | Re: Fixing pg_dump |