Re: [HACKERS] Teaching regex operators about collations
I wrote: Since ILIKE now responds to collations, it would be nice if the case-insensitive regex operators did too. The hard part of that is getting the information from src/backend/utils/adt/regexp.c to src/backend/regex/regc_locale.c. In principle we could probably add a field to the data structures carried around in the regex library, but that is looking a bit invasive, and since we share that code with the Tcl project I'm loath to change it too much. So what I'm thinking about is just having a couple of static variables in regc_locale.c that we initialize before each use of the regex library. This is a bit grotty, but there's no need for the regex library to be re-entrant, so it wouldn't cause any problems until that improbable day when somebody succeeds in multi-threading the backend. In the event, it seemed least messy to store a collation Oid in struct regex_t, but not to pass it down via the regex library's struct vars private data structure. So the interface to the regex library is clean and if anyone ever wants to get rid of the static variables, it'll just be necessary to fix the innards. David E. Wheeler da...@kineticode.com writes: Sounds reasonable. Is this something that CITEXT could take advantage of somehow? Right now, its using a nasty hack to make ILIKE and friends work properly You mean the alias operators? Doesn't seem that bad, and anyway you'd still need aliases to inject a non-default collation, I think. But more to the point, we're still a long way from being able to allow a collation that has special equality semantics, so I don't foresee being able to replace citext with a case insensitive collation anytime soon. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Teaching regex operators about collations
Since ILIKE now responds to collations, it would be nice if the case-insensitive regex operators did too. The hard part of that is getting the information from src/backend/utils/adt/regexp.c to src/backend/regex/regc_locale.c. In principle we could probably add a field to the data structures carried around in the regex library, but that is looking a bit invasive, and since we share that code with the Tcl project I'm loath to change it too much. So what I'm thinking about is just having a couple of static variables in regc_locale.c that we initialize before each use of the regex library. This is a bit grotty, but there's no need for the regex library to be re-entrant, so it wouldn't cause any problems until that improbable day when somebody succeeds in multi-threading the backend. Comments? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Teaching regex operators about collations
On Apr 9, 2011, at 2:40 PM, Tom Lane wrote: Since ILIKE now responds to collations, it would be nice if the case-insensitive regex operators did too. The hard part of that is getting the information from src/backend/utils/adt/regexp.c to src/backend/regex/regc_locale.c. In principle we could probably add a field to the data structures carried around in the regex library, but that is looking a bit invasive, and since we share that code with the Tcl project I'm loath to change it too much. So what I'm thinking about is just having a couple of static variables in regc_locale.c that we initialize before each use of the regex library. This is a bit grotty, but there's no need for the regex library to be re-entrant, so it wouldn't cause any problems until that improbable day when somebody succeeds in multi-threading the backend. Comments? Sounds reasonable. Is this something that CITEXT could take advantage of somehow? Right now, its using a nasty hack to make ILIKE and friends work properly… Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
