From: | Willy-Bas Loos <willybas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: log level of "drop cascade" lists |
Date: | 2019-01-11 12:50:34 |
Message-ID: | CAHnozTj+sVHa3h35WnDfmMaqkSjviJ3dHXAOLygpauvS2Zj+wQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Jan 10, 2019 at 4:44 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
>
> 1) BEGIN;
> DROP schema myschema CASCADE;
> ROLLBACK/COMMIT;
>
> 2) \d myschema.*
On Thu, Jan 10, 2019 at 5:04 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think that would be met with more complaints than kudos.
> "WARNING" is supposed to mean "there's probably something wrong here",
> and a report of a cascaded drop is not that.
>
OK, both are good points.
Since the list is truncated and possibly affects objects in other schemas,
I would recommend setting
SET log_min_messages = notice;
for that session (for anyone else reading this, no need to set it in the
settings file, the above is an sql command).
And then it is possible to view the full list in the log (e.g. after
rolling back the transaction with the drop query).
Cheers,
--
Willy-Bas Loos
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Farber | 2019-01-11 12:50:38 | How to always run UPDATE FROM despite missing records in the source table? |
Previous Message | Tony Shelver | 2019-01-11 11:06:01 | Re: Benchmark of using JSON to transport query results in node.js |