Re: Error with DEFAULT VALUE in temp table

On 13.09.2025 00:19, Tom Lane wrote:
> Fixed (and tested) in the attached.

Great! Thank you.


 > So that "else" action was unreachable, and the code failed
 > to set "istemp" true for its own temp schema.

As for dropping my own temp schema, it's still a bit inconsistent (as it 
was before):

     postgres=# select pg_my_temp_schema()::regnamespace;
      pg_my_temp_schema
     -------------------
      pg_temp_0
     (1 row)
     postgres=# drop schema pg_temp_0;
     DROP SCHEMA

     postgres=# select * from dropped_objects where object_type = 
'schema' and is_temporary \gx
     -[ RECORD 1 ]---+----------
     n               | 7
     classid         | 2615
     objid           | 16398
     objsubid        | 0
     original        | t
     normal          | f
     is_temporary    | t
     object_type     | schema
     schema_name     |
     object_name     | pg_temp_0
     object_identity | pg_temp
     address_names   | {pg_temp}
     address_args    | {}

object_identity is pg_temp, but object_name is pg_temp_0. But maybe 
that's okay. Anyway, I don't think that dropping my own temp schema 
makes sense.


Also I noticed that schema_name for temp functions doesn't match with 
object_identity (pg_temp vs pg_temp_1):

     postgres=# create function pg_temp.bar(int) returns int as 'select 
$1' language sql;
     CREATE FUNCTION
     postgres=# drop function pg_temp.bar(int);
     DROP FUNCTION

     postgres=# select * from dropped_objects where object_type = 
'function' and is_temporary \gx
     -[ RECORD 1 ]---+-----------------------
     n               | 8
     classid         | 1255
     objid           | 16412
     objsubid        | 0
     original        | t
     normal          | f
     is_temporary    | t
     object_type     | function
     schema_name     | pg_temp
     object_name     |
     object_identity | pg_temp_1.bar(integer)
     address_names   | {pg_temp,bar}
     address_args    | {integer}

There should be a call to get_namespace_name_or_temp somewhere, I guess.

If you say this should be fixed, I can come up with a patch later. But 
maybe it's trivial.


Thanks again!

-- 
Sergey Shinderuk        https://postgrespro.com/