我有一个PostgreSQL驱动的网络应用程序，它执行一些非必要的简单计算，包括从外部来源获取值，乘法和除法用于报告目的。今天出现超出numeric( 10, 4 )字段值域的乘法导致应用程序崩溃的错误。如果相关字段刚刚设置为null并生成通知，情况会好得多。错误的工作方式是，一个字段中的错误值导致多个视图变得不可用，虽然该地方的缺失值可能很难过但没有大问题，但阻止的视图仍然是应用程序工作所必需的。 / p>
现在我知道在这种特殊情况下，将该字段设置为numeric( 11, 4 )会阻止救助，但这当然只是推迟了手头的问题。由于错误发生在函数调用中，我也可以写一个异常处理程序;最后，人们可以检查被乘数或结果为理智值（但这本身有点奇怪，因为我要么必须根据幅度进行猜测，要么在另一个可能处理值的数值类型中进行乘法运算原则上，我的确无法确定其数量，因为外部来源）。
异常处理可能归结为，但是，这需要所有数值计算必须通过PL / pgSQL函数调用完成，并且必须在许多不同的地方实现。没有一个选项看起来特别可维护或优雅。所以问题是：我可以以某种方式配置PostgreSQL忽略一些或所有算术错误并在这种情况下使用默认值吗？如果是这样，可以按数据库完成，还是必须配置服务器？如果这是不可能的或坏主意，那么避免算术错误的最佳做法是什么？
澄清这不是关于如何重写numeric( 10, 4 )以使该字段可以保存1e6及以上值的问题，也不是关于使用的应用程序中的错误处理的问题DB。它更多的是关于是否存在操作符，函数调用，常规配置或最常用的一般模式来处理（非必要< / em>）计算通常会产生一个数字（或实际上是其他值类型），除了一些导致异常的输入，这是结果可以完全安全地被丢弃的时候。当单元格太窄而无法显示数字时，可以考虑Excel打印出####，或者JavaScript会给您NaN代替算术错误。返回null而不是提出异常在一般编程中可能是一个坏主意，但在特定情况下是合法的。
观察PostGreSQL error codes确实有例如invalid_argument_for_logarithm，invalid_argument_for_ntile_function，division_by_zero都在第22类 - 数据异常下组合在一起并且允许在函数体中进行异常处理，所以我也可以特别问：如何捕获所有类除了列出所有错误代码之外还有22个例外？，但我仍然希望采用更有原则的方法。
答案 0 :(得分：1)
可以说，numeric（没有类型修饰符）类型对你来说是正确的，如果你想尽可能地避免溢出（这似乎是“算术错误”的意思） 。
但是，仍有value overflows numeric format的可能性。
无法配置PostgreSQL，以免忽略数字溢出。
如果操作的结果无法在数据类型中表示，则 应该是错误。如果应用程序提供的数据可能导致错误，则应用程序应准备好处理此类错误而不是“崩溃”。不这样做是一个应用程序错误。