Re: Error with DEFAULT VALUE in temp table

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru>
Cc: Антуан Виолин <violin(dot)antuan(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Error with DEFAULT VALUE in temp table
Date: 2025-09-12 21:19:28
Message-ID: 2472716.1757711968@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sergey Shinderuk <s(dot)shinderuk(at)postgrespro(dot)ru> writes:
> Thank you for working on this. I see you've fixed the patch and
> committed it as a0b99fc1220. I tested it a bit and see some side effects
> which may be unintentional.

Many thanks for double-checking!

> 1. SCHEMA lost object_name.

Ugh. I was misled first by assuming that EventTriggerSQLDropAddObject
didn't have *other* pre-existing bugs, and second by overestimating
the test coverage for this function. In particular I thought that
this coding pattern:

if (is_objectclass_supported(object->classId))
{
...
}
else
{
if (object->classId == NamespaceRelationId &&
isTempNamespace(object->objectId))
obj->istemp = true;
}

meant that is_objectclass_supported() doesn't return true for
NamespaceRelationId --- a conclusion I should have realized was silly,
I guess. So that "else" action was unreachable, and the code failed
to set "istemp" true for its own temp schema. But I took it on faith
and supposed that we weren't filling objname for schemas.

I would have spotted the behavior change if event_trigger.sql
made any attempt to verify more than a few of the outputs of
pg_event_trigger_dropped_objects(), but it didn't. So the attached
patch fixes that test script to print all the expected-to-be-stable
outputs.

> 2. DEFAULT VALUE now has schema_name and object_name.

Setting schema_name is expected I think: you can hardly opine that
an object is temp unless it's associated with a temp schema.
You're right that setting object_name to the table name is the
wrong thing, and again I blame that on poor test coverage.

> Currently schema_name is null for triggers and policy objects, but that
> may be accidental.

Double ugh. Triggers and policy objects have this exact same bug.
Fixed (and tested) in the attached.

I'm tempted to wonder if the objectaddress.c ObjectProperty
infrastructure should grow some support for cases like these,
but right now I think it'd be about a wash in terms of the
amount of code added.

regards, tom lane

Attachment Content-Type Size
v1-fix-oversights-in-commit-a0b99fc12.patch text/x-diff 30.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-09-12 21:30:21 Re: [PATCH] Hex-coding optimizations using SVE on ARM.
Previous Message Nico Williams 2025-09-12 20:48:55 Re: PostgreSQL 18 GA press release draft