仅当添加条件的第二秒时，红移抛出无效的数字错误

Question

我正在使用Python查询一个格式不正确的红移服务器。我能够根据列的数字值像这样滤除非数字和查询：

import pyodbc
import pandas as pd
conn = pyodbc.connect(...)

q = '''
select *
from
(
    select 
    cast(oldcol as numeric) as newcol
    from tablename
    where oldcol similar to '[0-9]+(.[0-9]+)?' 
)
where newcol > 10
'''
pd.read_sql(q, conn)

但是，当我将Where语句更改为：

where newcol > 10 and newcol < 150

或者

where newcol between 10 and 150

我会收到以下错误：

ERROR:  Invalid digit, Value '-', Pos 2, Type: Decimal \nDETAIL:  \n  -----------------------------------------------\n  error:  Invalid digit, Value '-', Pos 2, Type: Decimal \n  code:      1207\n  context:   85-59\n  query:     82218981\n  location:  :0\n  process:   query1_125_82218981 [pid=0]\n  -----------------------------------------------\n\n (30) (SQLExecDirectW)")

但是在有一个'的地方不应有任何行- '在newcol中，因为否则第一个查询将无法正常工作，

where newcol similar to '%-%'

如果我使用另一个数字列，请转换为数字而不是数字，则不会返回相同的错误，请转换比较的顺序，使用不同的比较值，并使用光标= conn.cursor（）cursor.execute（q）执行代码。

Answer 1

如果这是优化器，则可以在其中不适当地进行条件，您可以尝试在该子句中应用一个冗余以解决这个问题。说...

where newcol > 10 and newcol < 150 and newcol::text similar to '[0-9]+(.[0-9]+)?'

这只是一个猜测可能有助于“脱离”问题的猜测。您可能需要使用此游戏来说服优化器做正确的事情。

这说我怀疑该问题在数据中更有可能。 “ - ”的报告可能只是红移不知道应该报告什么是数据，而不是实际上一部分数据。我对可能原因的最佳猜测是，被馈送给铸造的数据不适合数字（18,0）的默认数字数据类型。如果您的字符串数据值打破此类型定义，我可以看到此错误消息正在发生。

您可能没有看到原始查询中的错误的原因是它会产生大量的输出（或有限），并且查询在达到问题值之前会产生结果。尝试将原始查询的输出（没有顶部或限制）发送到临时表，然后查看它是否完成而没有错误作为测试。您也可以删除Where子句，看看是否所有内部查询的数据都可以处理。

这只是一个猜测，您看到的问题可能是数据期望问题，而不是RS错误。我过去曾见过RS错误（通常使用优化器），因此我永远不会排除这种可能性。

=================

在评论中来回一些后，RedShift可能会在其中推进一个条款。这就是可以工作的方式。

RedShift通过应用与Table Metadata的条款进行应用，从而获得了巨大的性能。优化器几乎可以肯定会弄平这组2个选择以获得性能。它可能尝试将外部子句 - “ newcol＆gt; 10和newcol＆lt; 150” - 并将其应用于源数据表的元数据。减少从磁盘上读取的行可能会有很大帮助。它将通过（有效地）更改到“铸造（数字）＆gt; 10并铸造（oldcol为数字）＆lt; 150”的地方来实现这一目标。完全有效，对吧？但是，不，这种演员仅应用于内部查询的某些行，而不是全部。

那么，如何修复 /证明它呢？

您的查询结构基本上是一个案例语句，但使用Where子句进行。您的WHERE子句正在“更改”数据如何处理。红移优化器不太可能以这种方式思考并越过（如果该理论成立）。如果我们将数据处理信息添加到查询的数据处理部分中，那么这应该有助于红移发现它不能按照所需的方式将查询弄平。

这是我尝试的实验：（

select *
from
(
    select 
    decode(oldcol similar to '[0-9]+(.[0-9]+)?', true, cast(oldcol as numeric)) as newcol
    from tablename
    where oldcol similar to '[0-9]+(.[0-9]+)?' 
)
where newcol > 10 and newcol < 150

decode（）只是一个缩短/简单的情况语法）

现在，优化器将需要将Decode（）带入扁平化条款并“保护”查询免受数据错误的情况。这种结构将使子句不需要的内心使人内心，但我们不要一次改变太多的事情。

如果这种情况有效，那么我们可能对正在发生的事情有良好的处理。不能保证这种理论在这种情况下是正确的，因为更改查询只是“移动”了问题，但这是“可能正确的”。此信息还将有助于创建一个简单的测试案例，以提交给AWS。