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 ts
On 16 Feb 2011, at 23:22, "David E. Wheeler" 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 didn't get
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
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
On Mon, 14 Feb 2011, Tom Lane wrote:
"David E. Wheeler" 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 st
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
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 thi
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
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.
>
On Mon, Feb 14, 2011 at 6:57 PM, Tom Lane wrote:
> "David E. Wheeler" 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 changi
On 14 February 2011 23:57, Tom Lane wrote:
> "David E. Wheeler" 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
"David E. Wheeler" 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.
It doesn't hel
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
───┼───┼──
13 matches
Mail list logo
