Re: Error with DEFAULT VALUE in temp table
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sergey Shinderuk <s.shinderuk@postgrespro.ru>
Cc: Антуан Виолин <violin.antuan@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-09-12T21:19:28Z
Lists: pgsql-hackers
Attachments
- v1-fix-oversights-in-commit-a0b99fc12.patch (text/x-diff) patch v1
Sergey Shinderuk <s.shinderuk@postgrespro.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
Commits
-
Fix oversights in pg_event_trigger_dropped_objects() fixes.
- ef81db9697a0 18.0 landed
- f14ea34d6e56 19 (unreleased) landed
- f6c8e7824c5d 16.11 landed
- a220e40d1106 17.7 landed
- 33e49ee014b0 15.15 landed
-
Report the correct is_temporary flag for column defaults.
- a0b99fc12203 19 (unreleased) landed
- c0c8ee23c896 17.7 landed
- 8856f1acc97b 16.11 landed
- 451373dc5c41 15.15 landed
- 3c02c46521b0 18.0 landed