Re: tsearch Parser Hacking
От
David E. Wheeler
Тема
Re: tsearch Parser Hacking
Дата
Msg-id
3C434EAE-819A-4FD0-ADEC-07A0EE955A14@kineticode.com
Ответ на
Re: tsearch Parser Hacking (Oleg Bartunov)
Список
Дерево обсуждения
tsearch Parser Hacking "David E. Wheeler" <david@kineticode.com>
Re: tsearch Parser Hacking Tom Lane <tgl@sss.pgh.pa.us>
Re: tsearch Parser Hacking "David E. Wheeler" <david@kineticode.com>
Re: tsearch Parser Hacking Sushant Sinha <sushant354@gmail.com>
Re: tsearch Parser Hacking Thom Brown <thom@linux.com>
Re: tsearch Parser Hacking David Blewett <david@dawninglight.net>
Re: tsearch Parser Hacking Oleg Bartunov <oleg@sai.msu.su>
Re: tsearch Parser Hacking "David E. Wheeler" <david@kineticode.com>
Re: tsearch Parser Hacking Jesper Krogh <jesper@krogh.cc>
Re: tsearch Parser Hacking Oleg Bartunov <oleg@sai.msu.su>
Re: tsearch Parser Hacking Oleg Bartunov <oleg@sai.msu.su>
Re: tsearch Parser Hacking "David E. Wheeler" <david@kineticode.com>
Re: tsearch Parser Hacking Oleg Bartunov <oleg@sai.msu.su>
On Feb 14, 2011, at 11:44 PM, Oleg Bartunov wrote: >> IMO, sooner or later we need to trash that code and replace it with >> something a bit more modification-friendly. > > We thought about configurable parser, but AFAIR, we didn't get any support for this at that time. What would it take to change the requirement such that *any* SQL function could be a parser, not only C functions? Maybe require that they turn a nested array of tokens? That way I could just write a function in PL/Perl quite easily. Best, David
В списке pgsql-hackers по дате отправления
