2

问题：在 Postgresql 中，如果 tabletemp_person_two继承自，则如果更改了父temp_person表，则忽略子表上的默认列值。

如何复制：

首先，创建表和子表。子表应该有一列具有默认值。

CREATE TEMPORARY TABLE temp_person (
    person_id SERIAL,
    name      VARCHAR
);

CREATE TEMPORARY TABLE temp_person_two (
    has_default character varying(4) DEFAULT 'en'::character varying NOT NULL
) INHERITS (temp_person);

接下来，在父表上创建一个触发器，将其数据复制到子表（我知道这看起来像是糟糕的设计，但这是一个显示问题的最小测试用例）。

CREATE FUNCTION temp_person_insert() RETURNS trigger
LANGUAGE plpgsql
AS '
BEGIN
INSERT INTO temp_person_two VALUES ( NEW.* );
RETURN NULL;
END;
';

CREATE TRIGGER temp_person_insert_trigger
    BEFORE INSERT ON temp_person
    FOR EACH ROW
    EXECUTE PROCEDURE temp_person_insert();

然后将数据插入父项并从子项中选择数据。数据应该是正确的。

INSERT INTO temp_person (name) VALUES ('ovid');
SELECT * FROM temp_person_two;
 person_id | name | has_default
-----------+------+-------------
         1 | ovid | en
(1 row )

最后，通过添加一个新的、不相关的列来更改父表。尝试插入数据并观察“非空约束”违规发生：

ALTER TABLE temp_person ADD column foo text;
INSERT INTO temp_person(name) VALUES ('Corinna');
ERROR:  null value in column "has_default" violates not-null constraint
CONTEXT:  SQL statement "INSERT INTO temp_person_two VALUES (  $1 .* )"
PL/pgSQL function "temp_person_insert" line 2 at SQL statement

我的版本：

testing=# select version();
                                                version
-------------------------------------------------------------------------------------------------------
 PostgreSQL 8.4.17 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit
(1 row)
4

2 回答 2

2

它一直存在到 9.3，但修复起来会很棘手，而且我不确定这是否只是不良行为而不是错误。

约束仍然存在，但请查看列顺序。

                                  Table "pg_temp_2.temp_person"
  Column   |       Type        |                            Modifiers                            
-----------+-------------------+-----------------------------------------------------------------
 person_id | integer           | not null default nextval('temp_person_person_id_seq'::regclass)
 name      | character varying | 
Number of child tables: 1 (Use \d+ to list them.)

                                  Table "pg_temp_2.temp_person_two"
   Column    |         Type         |                            Modifiers                            
-------------+----------------------+-----------------------------------------------------------------
 person_id   | integer              | not null default nextval('temp_person_person_id_seq'::regclass)
 name        | character varying    | 
 has_default | character varying(4) | not null default 'en'::character varying
Inherits: temp_person

ALTER TABLE
                                  Table "pg_temp_2.temp_person_two"
   Column    |         Type         |                            Modifiers                            
-------------+----------------------+-----------------------------------------------------------------
 person_id   | integer              | not null default nextval('temp_person_person_id_seq'::regclass)
 name        | character varying    | 
 has_default | character varying(4) | not null default 'en'::character varying
 foo         | text                 | 
Inherits: temp_person

它在您的第一个示例中有效，因为您正在有效地执行以下操作：

INSERT INTO temp_person_two (person_id,name)
VALUES (person_id, name)

但是看看你的新列在子表中的添加位置 - 最后！所以你最终得到

INSERT INTO temp_person_two (person_id,name,has_default)
VALUES (person_id, name, foo)

而不是你所希望的：

INSERT INTO temp_person_two (person_id,name,foo)...

那么 - 这里的正确行为是什么？如果 PostgreSQL 打乱了子表中可能破坏代码的列。如果没有，那也可能会破坏代码。碰巧的是，我认为第一个选项在没有大量 PG 代码更改的情况下是可行的，因此在中期不太可能这样做。

故事的寓意：明确列出您的 INSERT 列名。

手动可能需要一段时间。你知道任何带有正则表达式的语言吗？;-)

于 2013-10-07T17:59:32.913 回答
0

这不是一个错误。NEW.*扩展为新行中每一列的值，所以你正在做，如果你没有指定它INSERT INTO temp_person_two VALUES ( NEW.person_id, NEW.name, NEW.foo )，最后一个确实是（如果你做了错）。NULL

我很惊讶它甚至在您添加新列之前仍然有效，因为值的数量与子表中的字段数量不匹配。大概它假定缺少尾随值的默认值。

于 2013-10-07T15:16:33.100 回答