Thread

1. ALTER TABLE ... ADD COLUMN ... DEFAULT with volatile function loses DML

   Jeff Davis <pgsql@j-davis.com> — 2025-11-04T18:14:08Z

   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
   
   
   
   
   
   
   
   

2. Re: ALTER TABLE ... ADD COLUMN ... DEFAULT with volatile function loses DML

   Tom Lane <tgl@sss.pgh.pa.us> — 2025-11-04T18:22:32Z

   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
   
   
   
   

3. Re: ALTER TABLE ... ADD COLUMN ... DEFAULT with volatile function loses DML

   Jeff Davis <pgsql@j-davis.com> — 2025-11-04T19:20:38Z

   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