从视图返回 SQL 查询的 PL/SQL 函数体答案

【问题标题】：PL/SQL Function body returning SQL query from view从视图返回 SQL 查询的 PL/SQL 函数体
【发布时间】：2019-11-06 10:47:31
【问题描述】：

我正在尝试生成一些更复杂的东西。为了不产生很多查询和维护点，我们的想法是使用视图。

create or replace view vw_teste as
Select 1 
from dual
where 1 = '#VARIABLE_FIX';

我想做的是

DECLARE

sQuery VARCHAR2(32767);
sView VARCHAR2(32767);
BEGIN

SELECT a.TEXT
into sView
FROM all_views a 
where a.VIEW_NAME = 'VW_TESTE';

sQuery := REPLACE(sView, '''#VARIABLE_FIX''', :P1_ITEM);

return(sQuery);

END;

返回的错误：

“ORA-20999: 解析返回的查询结果在”ORA-20999: Failed to 解析 SQL 查询！

ORA-06550：第 12 行，第 23 列：ORA-00936：缺失表达
"

我什至将变量 sQuery 的内容插入到一个临时表中，结果与视图的内容是正确的。

我使用的是参数化视图，但是当我直接在oracle apex中返回查询时，报表的性能要快得多。

如果通过Squery:='Select 1 from dual where 1 =: P1_ITEM'，则返回成功。关于如何绕过错误并使用此方法的任何想法？

【问题讨论】：

我的第一个猜测是您将 #VARIABLE_FIX 替换为您未提供的输入参数。尝试在替换中使用 ':P1_ITEM' 而不是 :P1_ITEM
似乎您要解决一个问题，可能会引入性能问题和 SQL 注入风险。你真正想要解决的是什么？可以用 sys_context 解决吗？
您的代码存在另一个问题从没有所有者的 all_views 中选择可能导致重复值 ORA-01422：精确提取返回的行数超过请求的行数
一般来说，使用视图来帮助简化业务逻辑、通用连接等是好的。但是，就个人而言，我认为您正在尝试做的过度优化和潜在的限制。 PL/SQL 函数返回 SQL 查询由 Classic Reports（支持通用列）和 Interactive Reports（不支持通用列）不同地支持，而不是 Interactive Grids、LOV 等。当您使用这种灵活性时，它会出现技术债务和复杂性成本可能超过任何收益。
另外，与基于输入返回 SQL 查询的函数的包相比，使用视图有什么优势？

标签： oracle plsql oracle-apex oracle-apex-19.1

【解决方案1】：

你的陈述

sQuery := REPLACE(sView, '''#VARIABLE_FIX''', :P1_ITEM);

有太多引号 - 无需转义引号，因为您已经在视图定义中包含它们。将该行替换为

sQuery := REPLACE(sView, '#VARIABLE_FIX', :P1_ITEM);

你可以走了。在 19.1 上验证。但是，我可能会选择 Dan 的解决方案，并将查询放在一个带有函数的包中。这比在数据字典中查询视图定义要透明得多。

【讨论】：