On 16 Feb 2011, at 23:22, David E. Wheeler da...@kineticode.com wrote:
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
David,
as a cool perl guy you can easily take OpenFTS (openfts.sourceforge.net),
which provides perl interface to tsearch datatypes, and develop a
plperl version. That would be interesting for many people, who like flexibility
of perl. We personally use openfts in our web projects,i.e., we use
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
Hackers,
Is it possible to modify the default tsearch parser so that / doesn't get lexed
as a file token? That is, instead of this:
try=# select * from ts_debug('simple'::regconfig, 'w/d');
alias │description│ token │ dictionaries │ dictionary │ lexemes
David E. Wheeler da...@kineticode.com writes:
Is it possible to modify the default tsearch parser so that / doesn't get
lexed as a file token?
There is zero, none, nada, provision for modifying the behavior of the
default parser, other than by changing its compiled-in state transition
tables.
On 14 February 2011 23:57, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Is it possible to modify the default tsearch parser so that / doesn't get
lexed as a file token?
There is zero, none, nada, provision for modifying the behavior of the
default parser,
On Mon, Feb 14, 2011 at 6:57 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
Is it possible to modify the default tsearch parser so that / doesn't get
lexed as a file token?
There is zero, none, nada, provision for modifying the behavior of the
default
On Feb 14, 2011, at 3:57 PM, Tom Lane wrote:
There is zero, none, nada, provision for modifying the behavior of the
default parser, other than by changing its compiled-in state transition
tables.
It doesn't help any that said tables are baroquely designed and utterly
undocumented.
IMO,
I agree that it will be a good idea to rewrite the entire thing. However, in
the mean time, I sent a proposal earlier
http://archives.postgresql.org/pgsql-hackers/2010-08/msg00019.php
And a patch later:
http://archives.postgresql.org/pgsql-hackers/2010-09/msg00476.php
Tom asked me to look into
David,
it's not easy to hack tsearch parser, sorry. You can preparse your input
before to_tsquery,to_tsvector.
Oleg
On Mon, 14 Feb 2011, David E. Wheeler wrote:
Hackers,
Is it possible to modify the default tsearch parser so that / doesn't get lexed as a
file token? That is, instead of
On Feb 14, 2011, at 11:37 PM, Oleg Bartunov wrote:
it's not easy to hack tsearch parser, sorry. You can preparse your input
before to_tsquery,to_tsvector.
Yeah, I was thinking about s{/}{-}g before passing the values in. Might be the
only way to do it for now…
Thanks,
David
--
Sent via
On Mon, 14 Feb 2011, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
Is it possible to modify the default tsearch parser so that / doesn't get lexed as a
file token?
There is zero, none, nada, provision for modifying the behavior of the
default parser, other than by changing
On Mon, 14 Feb 2011, David E. Wheeler wrote:
On Feb 14, 2011, at 11:37 PM, Oleg Bartunov wrote:
it's not easy to hack tsearch parser, sorry. You can preparse your input
before to_tsquery,to_tsvector.
Yeah, I was thinking about s{/}{-}g before passing the values in. Might be the
only way to
13 matches
Mail list logo
