Re: tsearch Parser Hacking

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: tsearch Parser Hacking
Date: 2011-02-16 22:22:51
Message-ID: 3C434EAE-819A-4FD0-ADEC-07A0EE955A14@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-02-16 22:54:07 Re: arrays as pl/perl input arguments [PATCH]
Previous Message David E. Wheeler 2011-02-16 22:13:48 Re: contrib loose ends: 9.0 to 9.1 incompatibilities