Pervasive 普适SQL重用已删除的主键

我最近遇到了PSQL（v11）的一个非常奇怪的行为：

如果我创建一个带有标识列的表，添加一些记录，然后删除最后一行，那么这个rows键将被重用

create table "MyTable" (id identity not null, name varchar(50));

insert into "MyTable" (name) values ('Row 1');
insert into "MyTable" (name) values ('Row 2');
insert into "MyTable" (name) values ('Row 3');

select * from "MyTable"

到目前为止还不错

          id   name                                              
 ===========   ============
           1   Row 1                                             
           2   Row 2                                             
           3   Row 3

然后当我删除“第3行”

并添加一个新行

insert into "MyTable" (name) values ('Row 4');

我很惊讶地发现

         id   name                                              
===========   ==============
          1   Row 1                                             
          2   Row 2                                             
 !!! ---> 3   Row 4

---

是否有办法将服务器配置更改为以防止此行为。我也很乐意接受任何其他建议在普适SQL中创建一个可靠唯一的整数。

根据

自动增量

文档（），这似乎是预期的行为。具体而言，在文件中，它说：

如果您指示希望数据库引擎分配下一个 值通过在插入或更新中输入零（0）值 数据库只需查找最大的数字，添加1，然后插入 结果值。 因为在给出的示例中，最大数字是“2”，所以下一个自动增量值将是“3”。 在autoincrement使用中防止这种行为的唯一方法是在插入时指定值

如果您真的想要独特的东西，可以使用文档中描述的

UNIQUEIDENTIFIER

。
下面是一个例子：

create table "MyTable" (id identity not null, gid UNIQUEIDENTIFIER default newid(),  name varchar(50));

insert into "MyTable" (name) values ('Row 1');
insert into "MyTable" (name) values ('Row 2');
insert into "MyTable" (name) values ('Row 3');

select * from "mytable";
delete from "MyTable" where id = 3;
insert into "MyTable" (name) values ('Row 4');
select * from "mytable";

结果是：

<<<<<<<<<<<<<<<<<<<<<<<<
         id   gid                                    name                                              
===========   ====================================   ==================================================
          1   1F74A3E5-6EFC-4382-81DA-94F58710AD73   Row 1                                             
          2   B5FEFA7A-F85B-486A-A7CA-9615EAD1A601   Row 2                                             
          3   E327B2CF-D01D-4039-BB83-CAD966C72131   Row 3                                             


<<<<<<<<<<<<<<<<<<<<<<<<
         id   gid                                    name                                              
===========   ====================================   ==================================================
          1   1F74A3E5-6EFC-4382-81DA-94F58710AD73   Row 1                                             
          2   B5FEFA7A-F85B-486A-A7CA-9615EAD1A601   Row 2                                             
          3   66F0E55C-52CF-4183-87EE-2C0FDD6E45B6   Row 4                                             

---

查看SQL序列；-）PSQL完全不提供序列功能，尝试像中央序列存储这样的方法是非常有问题的，因为您一直都会得到页面锁，甚至是完整的表锁。您是否有任何实现序列（除了使用CISAM非托管调用）的普遍经验？不幸的是，我记得此行为在Btrieve端的事务中被报告为一个问题（客户在事务中插入1000条记录，中止事务，并尝试获取自动增量值，但得到的是1而不是插入的记录数）.我记得，这被认为是预期的行为。但我不记得这是SQL方面的问题。您使用的是什么接口？无法关闭密钥的重用values@mirtheil就像这样-有一篇很长的文章是关于AUTOINC字段何时“降低”的在pv 13文档的一节中。但他们似乎没有添加关闭该行为的方法。我使用ODBC BTW。这当然是一种获取唯一值的方法，但我担心我需要数据类型保持整数（这适用于不太可能重构代码的现有解决方案）正如您所说，这似乎是有文档记录的行为。您是否在现有代码中发现了问题？这是一种边缘情况：我们的一些PK被第三方程序使用，我们不希望冒险重新分配可能在某个地方引用的密钥。这就是为什么我们实现了一个非托管CISAM序列生成器，它工作正常，但我可以吗无法通过SQL使用。。。
<<<<<<<<<<<<<<<<<<<<<<<<
         id   gid                                    name                                              
===========   ====================================   ==================================================
          1   1F74A3E5-6EFC-4382-81DA-94F58710AD73   Row 1                                             
          2   B5FEFA7A-F85B-486A-A7CA-9615EAD1A601   Row 2                                             
          3   E327B2CF-D01D-4039-BB83-CAD966C72131   Row 3                                             


<<<<<<<<<<<<<<<<<<<<<<<<
         id   gid                                    name                                              
===========   ====================================   ==================================================
          1   1F74A3E5-6EFC-4382-81DA-94F58710AD73   Row 1                                             
          2   B5FEFA7A-F85B-486A-A7CA-9615EAD1A601   Row 2                                             
          3   66F0E55C-52CF-4183-87EE-2C0FDD6E45B6   Row 4