Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema
Date
Msg-id 20200108015601.GB3413@paquier.xyz
Whole thread Raw
In response to Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Assert failure due to "drop schema pg_temp_3 cascade" fortemporary tables and \d+ is not showing any info after drooping temp tableschema  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, Jan 07, 2020 at 07:55:17PM -0500, Tom Lane wrote:
> * Please revert a052f6c as a separate commit specifically doing that,
> so that when it comes time to make the release notes, it's clear that
> a052f6c doesn't require documentation.

Okay.  Committed the revert first then.

> * I think the check on log_min_messages <= LOG is probably wrong, since
> LOG sorts out of order for this purpose.  Compare is_log_level_output()
> in elog.c.  I'd suggest not bothering with trying to optimize away the
> get_namespace_name call here; we shouldn't be in this code path often
> enough for performance to matter, and nobody ever cared about it before.

Done.

> * I don't greatly like the notation
>     dropping orphan temp table \"%s.(null).%s\" ...
> and I bet Robert won't either.  Not sure offhand about a better
> idea --- maybe
>     dropping orphan temp table \"%s\" with OID %u in database \"%s\"

And done this way as per the attached.  I am of course open to
objections or better ideas, though this looks formulation looks pretty
good to me.  Robert?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Consolidate 'unique array values' logic into a reusable function?
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size