| From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: syntax of operation with tsearch's configuration |
| Date: | 2006-11-17 23:13:35 |
| Message-ID: | 20061117231335.GE25463@svana.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Nov 17, 2006 at 03:53:35PM -0500, Tom Lane wrote:
> > Having the supporting code in core does not make much of a difference
> > otherwise from having it in contrib, does it?
>
> Given the nonextensibility of gram.y and keywords.c, it has to be in
> core to even think about having special syntax :-(
Has anyone ever heard of extensible grammers? Just thinking wildly, you
could decree that commands beginning with @ are extensions and are parsed
by the module listed next. Then your command set becomes:
@tsearch CREATE PARSER ....
Then contrib modules can add their own parser. You'd have the overhead
of multiple lex/yacc parsers, but you wouldn't have to change the main
parser for every extension.
Has anyone ever heard of something like this?
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2006-11-17 23:25:17 | pgsql: Clarify description of CIDR-address column of pg_hba.conf, to |
| Previous Message | Nikolay Samokhvalov | 2006-11-17 22:35:28 | Re: Proposal: syntax of operation with tsearch's configuration |