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

On Mon, Jan 6, 2020 at 7:22 PM Michael Paquier <[email protected]> wrote:
> Okay for the first one, printing the OID sounds like a good idea.
> Like Tom, I would prefer keeping the relation name with "(null)" for
> the schema name.  Or even better, could we just print the OID all the
> time?  What's preventing us from showing that information in the first
> place?  And that still looks good to have when debugging issues IMO
> for orphaned entries.

I think we should have two different messages, rather than trying to
shoehorn things into one message using a fake schema name.

> For the second one, I would really wish that we keep the restriction
> put in place by a052f6c until we actually figure out how to make the
> operation safe in the ways we want it to work because this puts
> the catalogs into an inconsistent state for any object type able to
> use a temporary schema, like functions, domains etc. for example able
> to use "pg_temp" as a synonym for the temp namespace name.  And any
> connected user is able to do that.

So what?

> On top of that, except for tables,
> these could remain as orphaned entries after a crash, no?

Tables, too, although they want have storage any more. But your patch
in no way prevents that. It just makes it harder to fix when it does
happen. So I see no advantages of it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company