本文主要是介绍关于IvorySQL和OpenGauss包SPEC处理的一些思考,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
包的SPEC区可以定义下面三种类型(本篇只讨论SPEC区的情况)
- 变量
- 类型(nested table等)(注意这是包内定义的类型,与SQL创建的不通)
- 游标
这三种类型在PG原生中,是找不到相似的功能的:
- 变量:变量需要能够作用于所有PL代码中,PG中没有全局变量的这种概念,又因为PL的插件式设计和SQL层解耦,PL变量就算给SQL使用一般也只能用回调(PL的datums拼SQL的params)。
- 类型:这里的类型特指嵌套表、动态数组、关联数组。PG的类型全部放在pg_types中,不能在PL层创建。
- 游标:PG原生支持SQL层在事务内使用declare/fetch语法定义SQL层游标,但必须在事务块内;PG也支持在PL函数内定义游标,但能再当前函数内使用,不能跨函数。
三种类型有着不同的作用域:
SQL层 | PL层 | |
---|---|---|
变量 | 用于函数默认值 | 可当做全局变量随意使用 |
类型 | 无 | 可当做基础类型随意使用 |
游标 | 无 | 只能在定义包内使用,可跨函数使用 |
三种类型在PG中的实现方法:
- 变量:
- 每个包应该有自己的符号表(命名空间),可以由namespace.pkgname唯一指定到某一个符号表进行搜索。
- 这里IvorySQL使用pg_variable系统表来保存变量、游标(没实现集合类型),但不会存值,包变量本来就是session级的,按理说不需落盘,推测主要是用索引加速查找。
- OpenGauss的实现类似于内存中维护各个包的符号表,使用时先搜索函数自己的符号表,再去搜索包的符号表。全内存态没落盘,确实没必要落盘。
- 实现时可根据pkgname,先编译包,并生成包的符号表,SQL层可回调使用包变量,PL层可直接使用包变量。
- 在PL层使用时,例如
a := pkg.g_var;
,在PL parse时对二段解析增加搜索包命名空间的逻辑即可,不要发生deep copy,将包的datums拷贝到自己的datums中,这样的话会变得非常复杂,执行完还要拷贝回包空间中。
- 每个包应该有自己的符号表(命名空间),可以由namespace.pkgname唯一指定到某一个符号表进行搜索。
- 类型:分三类讨论
- 嵌套表、动态数组:
20230410:是现在内存中加一些旁路逻辑,增加类型的搜索范围。- 20231008:功能等价于数组,从生命周期上来看,包SPEC的类型和包的生命周期一致,从作用域来看,和pg_type中的类型范围有区别:例如SPEC的类型不能用于表字段,但能用于函数入参返回值;BODY中定义的PRIV的类型只能用于当前包。实现时可与SQL层的CREATE NESTED TABLE统一逻辑,做成标准类型记录在pg_type中,在增加字段表示作用域,可最大化复用PG原生逻辑。
- 关联数组:功能等价与哈希表,
- 高斯实现了类似于指针数组的功能,避免了PG多维数组的维度锁死的问题(第一次使用定义维度,后面无法修改),实现较为合理:《分析openGauss包内集合类型的实现方法》
- IvorySQL没实现。
- 嵌套表、动态数组:
这篇关于关于IvorySQL和OpenGauss包SPEC处理的一些思考的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!