Re: Future of our regular expression code

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Future of our regular expression code
Дата
Msg-id 2475.1329773725@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Future of our regular expression code  (Billy Earney <billy.earney@gmail.com>)
Ответы Re: Future of our regular expression code  (Billy Earney <billy.earney@gmail.com>)
Список pgsql-hackers
Billy Earney <billy.earney@gmail.com> writes:
> Also would it be possible to set a session variable (lets say  PGREGEXTYPE)
> and set it to ARE (current alg), RE2, or PCRE, that way users could choose
> which implementation they want (unless we find a single implementation that
> beats the others in almost all categories)?  Or is this a bad idea?

We used to have a GUC that selected the default mode for Spencer's
package (ARE, ERE, or BRE), and eventually gave it up on the grounds
that it did more harm than good.  In particular, you really cannot treat
the regex operators as immutable if their behavior varies depending on
a GUC, which is more or less fatal from an optimization standpoint.
So I'd say a GUC that switches engines, and thereby brings in subtler
but no less real incompatibilities than the old one did, would be a
pretty bad idea.

Also, TBH I have exactly zero interest in supporting pluggable regex
engines in Postgres.  Regex is not sufficiently central to what we do
to justify the work of coping with N different APIs and sets of
idiosyncrasies.  (Perl evidently sees that differently, and with some
reason.)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Billy Earney
Дата:
Сообщение: Re: Future of our regular expression code
Следующее
От: Billy Earney
Дата:
Сообщение: Re: Future of our regular expression code