Question

我在Redshift中遇到一个问题，在select语句中每列调用一次UDF会返回与第一次调用UDF相同的结果。

背景点

我有一个非常简单的Python UDF来计算md5哈希。此函数的原因是能够在执行哈希之前处理UTF-16 / UTF-8转换，因此它与SQL Server一致。现在函数内部的语法或逻辑似乎不是问题，因为我们已经尝试创建甚至更简单的函数来产生相同的行为。

问题

我的函数名为MD5_UTF16，通过执行MD5_UTF16（yourvalue）调用，并返回传递给参数的值的哈希字符串/ hexdigest。

在我的查询中，我需要能够做到这一点（postgresql语法）：

SELECT MD5_UTF16(column1) || MD5_UTF16(column2)|| MD5_UTF16(column3) AS concatenatedhash
FROM MyTable

即。我需要计算每个哈希并将它们连接在一个列中。如果我在它们自己的列中分别计算每个哈希值，则该函数会为这些列生成正确的哈希值。但是，在上面的例子中，我调用了每个函数，并将结果与其他调用的结果连接起来。在这种情况下发生的事情是对函数的所有调用都返回第一个调用的哈希值，即MD5_UTF16（column1）。

使用示例哈希值进一步澄清。让我们假设这些是上面每列的哈希值：

第1栏： 275AB169CBEE4550F752C634B9335AE0
第2栏： B2214041A94F50B027FE1DEEC4C8474C
第3栏：91050DAEFFEE20CDA2FC9914B6E4EBE9

我对concatenatedhash列的预期结果将是上述字符串的简单连接（275AB169CBEE4550F752C634B9335AE0B2214041A94F50B027FE1DEEC4C8474C91050DAEFFEE20CDA2FC9914B6E4EBE9）

相反，我得到的是第1列哈希3次串联：（275AB169CBEE4550F752C634B9335AE0275AB169CBEE4550F752C634B9335AE0275AB169CBEE4550F752C634B9335AE0）

在我的SELECT语句中，如果我先在第2列（而不是第1列）上调用了该函数，那么它将是第2列的重复哈希值。

有没有人遇到过这个？

注意：如果要从表中选择数据，则只能复制此行为。所以做一个：

SELECT MD5_UTF16('hard-coded value 1') || MD5_UTF16('hard-coded value 2')

没有表源的

将不会复制此行为。

解决方法我知道

我知道可能的解决方法，但我仍然希望我的方法能够正常工作，所以这个问题不是关于应用以下解决方法，而是更多地理解为什么上述方法不起作用。 - 解决方法：首先计算单独列中的每个哈希值，然后将它们连接起来。除其他事项外，这将对我们的结果产生潜在的性能影响。

编辑1 已经发现我所描述的问题只发生在我的查询中有连接时...即使连接表中没有任何列数据用于我的UDF调用，即

SELECT ...连接哈希.. FROM table1 加入表2 ...

删除连接似乎会导致哈希值正确计算。将使用这些新知识尝试解决方法。在涉及连接时，不确定它是否与运行UDF的执行计划有任何关系 - 即使连接表中没有任何列数据用于UDF调用。

在select语句中的单个列中多次调用Redshift中的Python UDF时出现错误的结果

0 个答案: