关于postgresql数据库正则的信息

请问一下PostgreSQL什么意思 请详述 谢谢

首先知道substring函数在PostgreSQL中的作用。在这段SQ语句中，substring是使用的substring(txt from reg)的形式，其中, txt是要进行正则匹配的源字符串，reg是匹配的正则表达式。如此，我们大概可以知道：这段代码的then其实就是用information进行一些正则表达式的匹配，然后获取匹配后的那段字符串。

这段代码中一共有3个substring函数调用，而执行的顺序则与它们出现的顺序相反，首先执行的是:

substring(information from E':step_1: \\*([0 -9]+)' )

它获得匹配step_1: *后面所跟的数字；假设information为:step_1: *1234a, 那么获得的就是1234；

接下来为第二substring, 它是用information来匹配上面获得的数字嵌入":"和".*:step_1:"的那段内容；

而最后一个substring，则是匹配第二个获得的字串，其中前为“loan_purpose: ”接下来为非换行符号的那部分字串(即获得以“loan_purpose: ”开始的所有非换行字符，遇到换行符就终止，不包括"loan_purpose: ")。

一个例子:

select substring( substring( information FROM': ' ||  substring(information from E':step_1: 

\\*([0-9]+)'

) ||'.*:step_1:') 

from E'loan_purpose: ([^\n]+)')

from (select 'start here: 1234loan_purpose: Hello World:step_1: *1234end'::character varying as information)

s

运行结果如图，

相关问答

Q1: PostgreSQL全文检索简介

PostgreSQL自带有一个简易的全文检索引擎，可以实现小规模数据量的全文检索功能。本文我们将引导介绍一下这个功能，对于小数据量的搜索这个功能是足够使用的，而无需搭建额外的ES等重量级的全文检索服务器。

PG的全文检索操作符是 @@ ，当一个 tsvector (文档)和 tsquery (条件)匹配时返回 true ，并且前后顺序无影响:

和普通的SQL查询一样，只要在 WHERE 条件中使用这个符号就代表使用全文检索条件筛选文档了。如:

@@ 操作符支持隐式转换，对于 text 类型可以无需强类型转换( ::tsvector 或 to_tsvector(config_name, text) )，所以这个操作符实际支持的参数类型是这样的:

tsquery 查询条件并不是简单的正则，而是一组搜索术语，使用并且使用布尔操作符 （AND）、 | （OR）和 ! （NOT）来组合它们，还有短语搜索操作符 - （FOLLOWED BY）。更详细的语法参见 此文档 。

此外，PostgreSQL还提供了两个相对简化的版本 plainto_tsquery 和 phraseto_tsquery 。

plainto_tsquery ( plainto_tsquery([ config regconfig, ] querytext text) returns tsquery )用户将未格式化的 text 经过分词之后，插入 符号转为 tsquery :

phraseto_tsquery ( phraseto_tsquery([ config regconfig, ] querytext text) returns tsquery )行为和 plainto_tsquery 行为类似，但是分词之后不是插入 而是 - (FOLLOWED BY):

使用索引可以加快全文检索的速度。对于全文检索来说，可选的索引类型是 GIN (通用倒排索引)和 GIST (通用搜索树)，官方文档更推荐使用 GIN索引 。创建一个 GIN 索引的范例:

也可以是一个连接列:

还可以单独创建一个 tsvector 列，为这个列创建索引:

除了普通的 ORDER BY 条件之外，PostgreSQL为全文检索提供了两个可选的排序函数 ts_rank([ weights float4[], ] vector tsvector, query tsquery [, normalization integer ]) returns float4 和 ts_rank_cd([ weights float4[], ] vector tsvector, query tsquery [, normalization integer ]) returns float4 ，以便实现基于 权重 的排序。

此外，对于PostgreSQL 9.6以上的版本还可以使用 RUM index 排序。(注意，这个是扩展，默认不包含)。

PostgreSQL默认的分词字典中并不包含中文分词字典，因此我们必须手工引入。目前一个比较好的项目是 zhparser ，同时这个插件也是阿里云的RDS默认包含的。安装和启用没什么好说的。值得一提的是分词配置参数。

在 CREATE EXTENSION 之后，必须配置分词参数才能正确进行分词和查找，否则什么都查不到。官方文档提供的一个配置策略是:

n,v,a,i,e,l 这几个字母分别表示一种token策略，只启用了这几种token mapping，其余则被屏蔽。具体支持的参数和含义可以用 \dFp+ zhparser 显示:

WITH simple 表示词典使用的是内置的simple词典，即仅做小写转换。根据需要可以灵活定义词典和token映射，以实现屏蔽词和同义词归并等功能。

比如我们看下面这个例子:

可以看到 江淮 这个词组在查询的时候被忽略了，我们启用 j (abbreviation,简称)再看看结果:

所以实际使用中要设置合理的token types，过少将导致搜索结果不准确，过多将导致性能下降。此外，还有一些诸如 短词复合: zhparser.multi_short = f 这一类的控制分词结果的选项，根据实际使用酌情开启。

Q2: 看大数据最大技术难关之模糊检索，PostgreSQL如何攻克

大数据正在向我们奔来。尽管业务场景不会完全相同，但在其中一个最典型场景——模糊检索中，技术需求却出奇的一致。

比如说：

物联网，往往会产生大量的数据，除了数字数据，还有字符串类的数据，例如条形码，车牌，手机号，邮箱，姓名等。假设用户需要在大量的传感数据中进行模糊检索，甚至规则表达式匹配，有什么高效的方法呢？

医药，市面上发现了一批药品可能有问题，需要对药品条码进行规则表达式查找，找出复合条件的药品流向。但怎么才能在如此复杂的系统中，用高效方法来实现？

公安，侦查行动时，有可能需要线索的检索。如用户提供的残缺的电话号码，邮箱，车牌，IP地址，QQ号码，微信号码等进行交叉搜索，根据这些信息加上时间的叠加，模糊匹配和关联，最终找出罪犯。但这个流程，可有高效方法？

相同的需求还有很多。几乎每一个模糊匹配的场景下，都需要正则表达式匹配，这和人脸拼图有点类似，我们已经看到强烈的需求已经产生。但技术方面，要怎么做更好？

在我看来：正则匹配和模糊匹配通常是搜索引擎的特长，但是如果你使用的是PostgreSQL数据库照样能实现，并且性能不赖，加上分布式方案

(譬如 plproxy, pg_shard, fdw shard, pg-xc, pg-xl,

greenplum)，处理百亿以上数据量的正则匹配和模糊匹配效果杠杠的，同时还不失数据库固有的功能，绝对是一举多得。

首先对应用场景进行一下分类，以及现有技术下能使用的优化手段。

.1. 带前缀的模糊查询，例如 like 'ABC%'，在PG中也可以写成 ~ '^ABC'

可以使用btree索引优化，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

.2. 带后缀的模糊查询，例如 like '%ABC'，在PG中也可以写成 ~ 'ABC$'

可以使用reverse函数btree索引，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

.3. 不带前缀和后缀的模糊查询，例如 like '%AB_C%'，在PG中也可以写成 ~ 'AB.C'

可以使用pg_trgm的gin索引，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

.4. 正则表达式查询，例如 ~ '[\d]+def1.?[a|b|0|8]{1,3}'

可以使用pg_trgm的gin索引，或者拆列用多列索引叠加bit and或bit or进行优化（只适合固定长度的端字符串，例如char(8)）。

PostgreSQL pg_trgm插件自从9.1开始支持模糊查询使用索引，从9.3开始支持规则表达式查询使用索引，大大提高了PostgreSQL在刑侦方面的能力。

代码见

pg_trgm插件的原理，将字符串前加2个空格，后加1个空格，组成一个新的字符串，并将这个新的字符串按照每3个相邻的字符拆分成多个token。

当使用规则表达式或者模糊查询进行匹配时，会检索出他们的近似度，再进行filter。

postgresql数据库正则的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、postgresql数据库正则的信息别忘了在本站进行查找喔。