| From: | Jesper Krogh <jesper(at)krogh(dot)cc> |
|---|---|
| To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
| Cc: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, 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-17 10:30:05 |
| Message-ID: | E47298A1-A85C-4256-86A5-C06E3DEEB6F0@krogh.cc |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 16 Feb 2011, at 23:22, "David E. Wheeler" <david(at)kineticode(dot)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 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.
I had just the same thought in mind. But so far I systematically substitute _ and a few other characters to ł which doesn't get interpreted as blanks. But more direct control would be appreciated
Jesper
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Magnus Hagander | 2011-02-17 10:36:23 | Re: Debian readline/libedit breakage |
| Previous Message | rsmogura | 2011-02-17 10:18:17 | Re: Fwd: [JDBC] Weird issues when reading UDT from stored function |