标签: postgresql

对于一个项目，我创建了一个带有列的表price MONEY NOT NULL。而且我认为它会正确处理小数，与浮点数（即 IEEE 舍入问题）不同，但我最终$9.94从数据库返回了像（字符串）这样的值，而不是9.94（数字）。必须通过删除美元符号来手动操作字段值是愚蠢的；有没有办法让一MONEY列没有货币符号？

如果不是，处理货币价值的最佳数据类型替换是什么？

我已经读到 PostgreSQL 通常可以使用多个索引，但是在跨两个索引的查询的特定情况下，它会同时使用两个索引吗？如果是这样，它们是按顺序加载还是一起加载？

例如，如果此查询跨越两个部分索引 by column_1，将如何使用部分索引，以及如何加载和丢弃索引数据：

SELECT 1 FROM sample_table WHERE column_1 > 50 AND column_2 < 50000

We are running many Linux VM's in a vmware/shared storage environment, each running its own instance of postgreSQL (a mix of 9.0 and 9.3). Currently, the entire VM sits on a single root partition/volume, and we've had great success (~8 years) using storage-based snapshots of the underlying VMFS volumes for backup/restore process (and replication to our DR site).

Due to the architecture of our storage, it would be advantageous to separate postgres WAL files to a non-cached, mostly-write volume to …

在 Postgres 中，我们使用以下代码获取异常的“堆栈跟踪”：

EXCEPTION WHEN others THEN
    GET STACKED DIAGNOSTICS v_error_stack = PG_EXCEPTION_CONTEXT;

这适用于“自然”异常，但如果我们使用

RAISE EXCEPTION 'This is an error!';

...然后没有堆栈跟踪。根据邮件列表条目，这可能是故意的，尽管我终生无法弄清楚原因。这让我想找出另一种抛出异常的方法，而不是使用RAISE. 我只是错过了一些明显的东西吗？有没有人有这个技巧？我可以让 Postgres 抛出一个包含我选择的字符串的异常，这样我不仅可以在错误消息中获得我的字符串，还可以获得完整的堆栈跟踪吗？

这是一个完整的例子：

CREATE OR REPLACE FUNCTION error_test() RETURNS json AS $$
DECLARE
    v_error_stack text;
BEGIN

    -- Comment this out to see how a "normal" exception will give you the stack trace
    RAISE EXCEPTION 'This exception will not get a stack trace';

    -- This will give a divide by zero error, complete with stack …

我想将用户 ID 存储在自定义会话变量中，并在触发器过程中使用（读取）它来授权用户操作。我发现了这样的东西：

set session "myapp.user" = '12345';
...
SELECT current_setting('myapp.user');

它似乎有效 - 我认为“myapp.user”应该在 .conf 文件中声明，但似乎我可以即时创建会话变量（我根本没有更改 .conf 文件）。

这样做有什么坏处吗？

我在一张桌子上有 2 个触发器；一种适用于插入：

CREATE TRIGGER "get_user_name"
AFTER INSERT ON "field_data"
FOR EACH ROW EXECUTE PROCEDURE "add_info"();

这会更新表中的一些值。
还有一个用于更新（填充历史表）：

CREATE TRIGGER "set_history"
BEFORE UPDATE ON "field_data"
FOR EACH ROW EXECUTE PROCEDURE "gener_history"();

问题是，当我在表中插入新行时，该过程"add_info"()会进行更新并因此触发第二个触发器，该触发器以错误结束：

ERROR:  record "new" has no field "field1"

Run Code Online (Sandbox Code Playgroud)

我怎样才能避免这种情况？

我需要为一个项目维护一个统计表，由项目列表及其使用情况组成（想想像一个网站，你想在其中计算浏览量）。每次实例化一个项目时，我都需要增加特定项目的使用量。

我的第一个实现是：

statistics(
  id      integer NOT NULL,
  name    character varying(255) NOT NULL,
  usage   integer NOT NULL DEFAULT 0,
);


UPDATE statistics 
  SET usage = usage + 1
WHERE name = '<name>';

我担心的是性能和并发性。更新过程将由几十个（可能是 80-120 个）设备实例化，并且每秒可能发生几次，所以我的问题是：

1）这个方法会保持并发吗？（即，如果多个设备“同时”请求更新，每个请求都会被计算在内吗？）

2）你能建议一个最好的方法来实现结果吗？我希望在写入更新时有负载，而读取会更频繁。是否存在增加值的特定函数？我在看“序列”，但我不确定这是否是正确的方法......

非常感谢您的任何建议

最近我确实以超级用户的身份创建了一个表，其中包括一个序列号列，例如，

create table my_table
(
    id serial primary key,
    data integer
);

因为我希望我的非超级用户用户拥有对该表的写访问权限，所以我授予了它权限：

grant select, update, insert, delete on table my_table to writer;

在这样做之后的随机时间点，该用户所做的插入开始失败，因为该用户没有修改my_table_id_seq与串行列关联的序列的权限。不幸的是，我无法在我当前的数据库上重现它。

我通过授予用户所需的权限来解决这个问题，如下所示：

grant all on table my_table_id_seq to writer;

有人可以帮我理解

• 为什么，在某些时候，以前足够的权限可能会开始失败？
• 为具有串行列的表授予写权限的正确方法是什么？

针对此数据库的全文查询（存储 RT（请求跟踪器）票证）似乎需要很长时间才能执行。附件表（包含全文数据）大约为 15GB。

数据库模式如下，大约有 200 万行：

rt4=# \d+ 附件
                                                    表“public.attachments”
     专栏 | 类型 | 修饰符 | 存储 | 描述
-----------------+------------------------------------------+-- -------------------------------------------------- -------+----------+-------------
 身份证 | 整数 | not null default nextval('attachments_id_seq'::regclass) | 平原 |
 交易ID | 整数 | 不为空| 平原 |
 家长 | 整数 | 非空默认值 0 | 平原 |
 消息ID | 字符变化(160) | | 扩展 |
 主题 | 字符变化(255) | | 扩展 |
 文件名 | 字符变化(255) | | 扩展 |
 内容类型 | 字符变化(80) | | 扩展 |
 内容编码 …

我在这里问了一个问题：https : //stackoverflow.com/questions/43807566/how-to-divide-two-values-from-the-same-column-but-at-different-rows

关于将同一表中同一列但不同行的值进行除法。现在我的问题是我有更多的分子和分母（不同的uns）。仍然是self join用 Postgres 解决这个问题的好方法还是有更好的解决方案？

例子：

| postcode | value | uns |
|----------|-------|-----|
|       AA |    40 |  53 |
|       BB |    20 |  53 |
|       AA |    10 |  54 |
|       AA |    20 |  55 |
|       AA |    10 |  56 |
|       AA |    30 |  57 |
|       AA |    50 |  58 |
|       BB |    10 |  54 |
|       BB | …