Обсуждение: ALTER TABLE ... ADD COLUMN ... DEFAULT with volatile function loses DML

This doesn't represent an actual use case, it's just a contrived test.

The docs say:

"Adding a column with a volatile DEFAULT (e.g., clock_timestamp()), a
stored generated column, an identity column, or a column with a domain
data type that has constraints will cause the entire table and its
indexes to be rewritten. Adding a virtual generated column never
requires a rewrite."

https://www.postgresql.org/docs/current/sql-altertable.html (in Notes
section).

The following SQL seems to lose the updates during the ALTER:

  CREATE TABLE t(id INT);
  INSERT INTO t VALUES (1), (2);

  CREATE FUNCTION f() RETURNS INT VOLATILE AS $$
    BEGIN
      UPDATE t SET id = id + 10;
      RETURN (SELECT MAX(id) FROM t);
    END
  $$ LANGUAGE plpgsql;

  ALTER TABLE t ADD COLUMN c INT DEFAULT f();

  SELECT * FROM t;

   id | c
  ----+----
    1 | 12
    2 | 22
  (2 rows)

It happens because the updates happen on the old heap while the
function is being evaluated, and the old heap is thrown away. But
uncontrolled DML happening during an ALTER seems hard to even define,
so I'm not sure how to fix it, or if we even need to fix it.

Thoughts?

Regards,
    Jeff Davis

Jeff Davis <pgsql@j-davis.com> writes:
> The following SQL seems to lose the updates during the ALTER:

>   CREATE TABLE t(id INT);
>   INSERT INTO t VALUES (1), (2);

>   CREATE FUNCTION f() RETURNS INT VOLATILE AS $$
>     BEGIN
>       UPDATE t SET id = id + 10;
>       RETURN (SELECT MAX(id) FROM t);
>     END
>   $$ LANGUAGE plpgsql;

>   ALTER TABLE t ADD COLUMN c INT DEFAULT f();

>   SELECT * FROM t;

>    id | c  
>   ----+----
>     1 | 12
>     2 | 22
>   (2 rows)

Hmm ... ideally we'd throw an error for that.  CheckTableNotInUse()
intends to prevent some similar cases, but it misses this one because
ALTER TABLE is the outermost command and there's no check performed
at the inner UPDATE.  Not sure how hard we need to work at preventing
people from shooting themselves in the foot, though.

            regards, tom lane

On Tue, 2025-11-04 at 13:22 -0500, Tom Lane wrote:
> Hmm ... ideally we'd throw an error for that.  CheckTableNotInUse()
> intends to prevent some similar cases, but it misses this one because
> ALTER TABLE is the outermost command and there's no check performed
> at the inner UPDATE.  Not sure how hard we need to work at preventing
> people from shooting themselves in the foot, though.

I poked around at a few ideas and they seemed to get invasive. Perhaps
the cure is worse than the disease, unless someone has an idea.

Regards,
    Jeff Davis