From: | Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru> |
---|---|
To: | Emre Hasegeli <emre(at)hasegeli(dot)com> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Prefix operator for text and spgist support |
Date: | 2018-04-16 12:50:36 |
Message-ID: | 20180416155036.36070396@wp.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 16 Apr 2018 12:45:23 +0200
Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:
> > Thank you, pushed with some editorization and renaming
> > text_startswith to starts_with
>
> I am sorry for not noticing this before, but what is the point of this
> operator? It seems to me we are only making the prefix searching
> business, which is already complicated, more complicated.
Hi.
>
> Also, the new operator is not documented on SQL String Functions and
> Operators table. It is not supported by btree text_pattern_ops or
> btree indexes with COLLATE "C". It is not defined for "citext", so
> people would get wrong results. It doesn't use pg_trgm indexes
> whereas LIKE can.
It is mentioned in documentation, look for "starts_with" function.
Currently it's working with spgist indexes which fact is pointed out in
the documentation too. I was going to add btree support but it would
require a new strategy so it will be matter of another patch. I think
this operator could be used in LIKE instead of current weird comparison
operators.
--
---
Ildus Kurbangaliev
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2018-04-16 13:09:24 | Re: Postgres 10 problem with UNION ALL of null value in "subselect" |
Previous Message | Laurenz Albe | 2018-04-16 12:32:10 | Re: SHOW ALL does not honor pg_read_all_settings membership |