On Sat, 2006-11-18 at 00:13 +0100, Martijn van Oosterhout wrote: > 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?
(not specifically answering Martijn...) The main thought for me on this thread is: Why do we need to invent *any* grammar to make this work? Why not just use functions? For PITR we have pg_start_backup() rather than BACKUP START. For advisory locks we have pg_advisory_lock() What's wrong with having pg_tsearch_ functions to do everything? There's nothing wrong with additional catalog tables/columns that are manipulated by function calls only. We have that already - look at pg_stat_reset() - no grammar stuff there. Anybody with an Oracle or SQLServer background is used to seeing system functions available as function calls; as I've observed above, so are we. We should keep the grammar clean to allow a very close adherence to SQL standards, IMHO. I would like to see Oleg and Teodor's good work come into core, but I don't want to see bucketfuls of new grammar issues. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
